|
|
ARCHIVE: TCP-IP Distribution List - Archives (1994)
DOCUMENT: TCP-IP Distribution List for June 1994 (648 messages, 341113 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1994/06.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.
START OF DOCUMENT
-----------[000000][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 1994 00:51:51 GMT From: rwoodard@pafosu2 (Robert Woodard) To: comp.protocols.tcp-ip Subject: Re: Wierd netork behaviour
Mathias Koerber (mathias@solomon.technet.sg) wrote: : Hi there. : I am at my wit's end. : I have a local network (Thin Ethernet) with : 2 ICL DRS/6000 : 2 IBM RS/6000 : 1 Linux PC : ~50 DOS/Windows PCS : 1 Netblazer PN1 (V2.3) : Thw whole net in on one line, no subntting etc sone. : since yesterday, I experience a wierd bahaviour. : It seems that the two ICL systems have grave difficulty talking : to the netblazer, while the IBM and the PCs can talk. Then : once in a while I have total outages, and things come : back very slowly. First only the IBMS talk to each other, : then they can alk to one of the ICLs, but none can talk to : the blazer. Later, things change around ... : I see very long return times (4000ms) from one machine to the : blazer, while other have 0. One machine sees ICMP port unreachables : from the other machine while talking to the blazer. : etc, etc, etc. : Sadly, I have no sniffer nor any other analyzer. I have changed a few : cables and checked them with a multimeter. that's about all I have. Hi Mathais, The only time I've seen this happen, a tech had used 75 ohm cable instead of RG-58. The closer the nodes were to each other, the better they could communicate. The further apart, the worse things became. Hope this helps, Woody
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 01:19:13 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: How do you determine SO_KEEPALIVE parameters?
> I've heard that when Unix socket connections are made, there is an option > that can be used to determine if that connection ever goes down. > The call is to setsockopt() and the option is SO_KEEPALIVE. The way > I heard that this works is > that when this option is set, idle time is measured and if a socket > connection is idle for X amount of time, a TCP message is sent on > the socket and a response is expected back. If a response is not > received in Y amount of time, the TCP message is sent again. > If no response is received in Z iterations, the socket is closed. > > Now here is my question...On the Unix system, would you have any idea > where X, Y, and Z are defined? X = 2 hours, Y = 75 seconds, and Z = 8 times. Most Unix systems that I've seen use the same values. > I've looked in W. Richard Steven's Unix Network Programming book but it > seems to leave this detail out. Check out Chapter 23 of my recent book "TCP/IP Illustrated" (Addison-Wesley, 1994) for a complete chapter on all the gory details on how keepalive works. Appendix E of this book contains details on changing the X, Y, and Z parameters for 5 popular flavors of Unix. Rich Stevens
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 02:43:13 GMT From: robs@join.com (Rob Stevens) To: comp.unix.solaris,comp.protocols.tcp-ip Subject: Berkeley Packet Filter (BPF) for Solaris2.3
Has anyone out there, whether Public Domain or Commercial, configured the Berkeley Packet Filter as a loadable STREAMS module that is usable with Solaris2.x? Thanx Rob Stevens
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 03:02:39 GMT From: robs@join.com (Rob Stevens) To: comp.protocols.tcp-ip Subject: Transport Provider Interface Spec. (TPI)
Anyone know an FTP site where a copy of the TPI spec. (Transport Provider Interface) can be found? Prefer postcript, but ordinary text would do. Thanx Rob Stevens
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 04:33:20 GMT From: d00n@crash.cts.com (Kevin Spousta) To: comp.protocols.tcp-ip Subject: /etc/hosts /etc/named.data questions
I've been working on an SMTP gateway for Word Perfect Office and some of the 'trickery' I've done involves multiple hostnames for a single IP address in the /etc/hosts file on our nameserver. Not being a total TCP/IP guru, I have raised more than a few eyebrows with the way I've set up the nameservice for this machine. I have 5 entries pointing to the same IP address and also mail exchange records in the /etc/named.data file to 'fake out' the machine called smtpgate into thinking it's many machines for addressing reasons. (Political reasons really) Is this OK? So far it works like a charm, but the keepers of the DNS say I can't do it like this. Is it ok to have 1 IP for multiple hosts, when the actual host is *ONE* machine? I'm defending my position on the grounds that A) it works, and B) nothing seems to be affected by this 'trickery'. Can someone prove/disprove my thinking??
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 04:41:38 GMT From: d00n@crash.cts.com (Kevin Spousta) To: comp.protocols.tcp-ip Subject: Mosaic "DNS Lookup Failure" problem..
Subject says it all.. Computer is a Compaq 486-dx2/66 running on a 4mbps Token Ring network, Wollongong Pathways 3.0 and Mosaic Release 2 Alpha 3. I can Telnet/FTP/Ping to my heart's content but Mosaic chokes with DNS lookup failures. I have Mosaic running not only on my OS/2 machine at work (16m T/R), but on about 20 Ethernetted PC running Pathways and even via SLIP from my OS/2 machine at home, but this one PC is driving me bananas. I've checked and double checked the Pathways and Mosaic configuration, the entries in the /etc/hosts file for this machine and even re-run the update_nameserver script on the DNS to propogate changes across the 'net to make sure, but the %^%*& thing still chokes. Hell, I'm even receiving mail within the mailer that comes with Pathways so I'm pretty sure the machine is config'd correctly. This version of Mosaic comes right off my OS/2 machine at work, with the *ONLY* change to the .INI file being the E-mail address of the machine's "owner" as opposed to my address. The only other thing I can think of is the 4mbps speed of his ring, compared to the 16mbps of the ring my machine is attached to. What's the deal? Is this machine possessed, or is it time I changed careers? :)
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 04:46:15 GMT From: mintz@cup.hp.com (Ken Mintz) To: comp.protocols.tcp-ip Subject: Re: How do you determine SO_KEEPALIVE parameters?
Ben Choi (choi@cso.geg.mot.com) wrote: > connection is idle for X amount of time, a TCP message is sent on > the socket and a response is expected back. If a response is not > received in Y amount of time, the TCP message is sent again. > If no response is received in Z iterations, the socket is closed. > > Now here is my question...On the Unix system, would you have any idea > where X, Y, and Z are defined? The setsockopt(2) man page should tell you this. But some such man pages are incorrect, it they tell you at all. Rich Stevens already posted the "standard" values, at least for a BSD derivative system (2 hours, 75 seconds and 8 times, respectively). And before we get too critical of these numbers (which most us agree are too long to be useful), please note that RFC-1122 "requires" that 2 hours be the default. (IMHO, the default should be a "local matter".) Some systems provide a command interface to tune these parameters. Alternatively, on BSD derivatives, the kernel variable tcp_keepidle controls X, tcp_keepintvl controls Y, and Z is hardcoded, typically. The units for the two kernel variables are typically __half-seconds__. But be wary of changing these variables, not only because of potential variations in individual vendor implementations, but also because of internal dependencies on these values for unrelated purposes. Also, changing these values have __global__ impact on all TCP connections, which could have unwanted side-effects. -- Ken Mintz
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 1994 05:42:48 GMT From: landmark@cs.tu-berlin.de (Torsten Kerschat) To: comp.protocols.tcp-ip Subject: Re: Transport Provider Interface Spec. (TPI)
robs@join.com (Rob Stevens) writes: >Anyone know an FTP site where a copy of the TPI >spec. (Transport Provider Interface) can be found? >Prefer postcript, but ordinary text would do. The TPI was specified by UNIX International, which in fact doesn't exist anymore. Therefore, you can't connect to the appropriate file server. But in fact, I will put the PS file (I can't do it by myself) on our anonymous ftp server, for further availablity. ftp.prz.tu-berlin.de:/net_doc/misc/tpi.ps.gz (please remember that the connectivity is sometimes very slow to our fileserver). I hope that our service-team will install it as soon as possible. Torsten -- Torsten Kerschat - Interdepartmental Research Center for Process Control Technical University of Berlin (PRZ - Room HE 104) Internet: torsten@prz.tu-berlin.d400.de / landmark@cs.tu-berlin.d400.de Phone : ++49 / (0)30 / 314 - 26822 Fax: ++49 / (0)30 / 314 - 21114
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 1994 05:50:03 GMT From: tli@cisco.com (Tony Li) To: comp.protocols.tcp-ip Subject: Re: IP Loadsharing
In article <2s5gth$62s@hacgate2.hac.com> switt@triceratops.hac.com (Steve
Witt) writes:
It is my understanding that a routing policy or protocol, like OSPF,
executing as a daemon (such as gated), initializes and updates the IP
routing table that IP uses to forward IP datagrams. The routes in the
IP routing table, indicate the next-hop router to which to forward IP
datagrams for specific destinations (either hosts or networks). If the
routing protocol is capable of discovering multiple routes to a
destination host or network, is IP capable of using this information?
It would seem that the IP routing table would need to have each route
from the set of multiple routes to a destination, inserted into the
table and then IP would need to have some method of using each route.
My understanding of current IP implementations (which is limited to the
4.3BSD from which SunOS was developed) is that the IP routing algorithm
first tries to find a host- specific route for the datagram, then tries
to find a network route for the datagram, and then uses a default route
(if it exists). It would seem that if there were multiple entries in
the IP routing table for a destination network or host that the IP
routing algorithm would match on the first one found and forward the
datagram accordingly and would not be able to make use of multiple
routes effectively. Perhaps I have a naive understanding of the IP
routing algorithm.
Can IP (or particular implementations of IP) perform load sharing given a
routing policy that is capable of discovering useful multiple routes to a
destination?
You're looking at one implementation. Other implementations do support
load sharing across multiple routes. It can be done in a variety of ways,
but the simple one is to structure the routing table such that all routes
for a destination exist in some close proximity and that you can easily
switch between the entries. A pointer into an array will work very
nicely...
Tony
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 94 05:51:18 GMT From: hal9001@panix.com (Robert A. Rosenberg) To: comp.protocols.tcp-ip Subject: Re: rfc1219 Implementation ??, (On the Assignment of Subnet Numbers)
In Article <dox.770306336@slbh04>, dox@bln.sel.alcatel.de (Guntram Dox) wrote: >If you prefer PM, then please email to >frohmuel@bln.sel.alcatel.de and NOT to this sender since it is still not >reachable from outside. If you add a "Reply To:" header to messages of this type, any EMAIL (as opposed to News Follow-Up) Replies would automatically get routed/sent to your intended EMAIL address and not direct to your address.
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 1994 14:12:21 -0500 From: elpede@news.mcc-care.com (Eric Pederson) To: comp.protocols.tcp-ip Subject: Re: /etc/hosts /etc/named.data questions
Kevin Spousta (d00n@crash.cts.com) wrote: : I've been working on an SMTP gateway for Word Perfect Office and some of the : 'trickery' I've done involves multiple hostnames for a single IP address in : the /etc/hosts file on our nameserver. Not being a total TCP/IP guru, I : have raised more than a few eyebrows with the way I've set up the nameservice : for this machine. : I have 5 entries pointing to the same IP address and also mail exchange : records in the /etc/named.data file to 'fake out' the machine called : smtpgate into thinking it's many machines for addressing reasons. (Political : reasons really) Is this OK? So far it works like a charm, but the keepers : of the DNS say I can't do it like this. : Is it ok to have 1 IP for multiple hosts, when the actual host is *ONE* : machine? I'm defending my position on the grounds that A) it works, and : B) nothing seems to be affected by this 'trickery'. Can someone : prove/disprove my thinking?? There's nothing wrong with multiple A records for one IP number, as long as you realize that you can only have one of those host names in your inverse name database. Many sites on the Internet have more than one A record for a single IP address. If you are a DNS purist you may not care for this, but as you said, it does work. -- ------------------------------------------------- Eric L. Pederson eric@mcc-care.com System Administrator (612) 996-2751 MCC Behavioral Care, Inc.
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 1994 14:25:54 -0400 From: news@vdd.VLSI.LL.MIT.EDU To: comp.protocols.tcp-ip,comp.security.unix Subject: ftp ACCT feature?
I need to implement the account (ACCT) feature of ftpd in the wu-archive source of ftpd, in order to require an extra security password before the user is allowed to do anything. Has anyone done this? Its the yacc stuff I'm not sure of, and how it should fit with the PASS command. George Young, Rm. B-169 young@vlsi.ll.mit.edu MIT Lincoln Laboratory young@vdd.vlsi.ll.mit.edu 244 Wood St. [129.55.11.1] Lexington, Massachusetts 02173-9108 (617) 981-2756
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 07:51:48 GMT From: cpm@uniplex.co.uk (Chris P Murray) To: comp.protocols.tcp-ip Subject: Re: server fails when client crashes...
Barry Margolin (barmar@think.com) wrote: : In article <1994May27.180801.5613@sal.wisc.edu> jwp@bernie.sal.wisc.edu (Jeffrey W Percival) writes: : > client dies : > server's select() indicates client writeable : > server calls write(sock, data, n) where n > 0 : > write() fails, DOES NOT RETURN (I just get my unix prompt back : > in the server window.) : My guess is that write() is sending a signal (EPIPE, EIO?) instead of : returning an error code, and the signal's default behavior is to kill the : process. But in this case I would expect the shell in the server window to : give the reason for the process exiting. However, I think the C shell : doesn't print a message for EPIPE -- it's too common an error (e.g. : "command | head" almost always exits for this reason), so it's probably this. The write() call is meant to generate a SIGPIPE signal when the receiver has terminated. It should return errno=EPIPE and indicate nothing has been written. Install a SIGPIPE signal handler or ignore it to stop your process exiting. Then use the handler and/or the return code from write() to notice when the client dies.
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 94 10:49:25 GMT From: sej@flowbee.interaccess.com (Stephen Johnson) To: comp.protocols.tcp-ip Subject: Re: /etc/hosts /etc/named.data questions
d00n@crash.cts.com (Kevin Spousta) writes: >I've been working on an SMTP gateway for Word Perfect Office and some of the >'trickery' I've done involves multiple hostnames for a single IP address in >the /etc/hosts file on our nameserver. Not being a total TCP/IP guru, I >have raised more than a few eyebrows with the way I've set up the nameservice >for this machine. >I have 5 entries pointing to the same IP address and also mail exchange >records in the /etc/named.data file to 'fake out' the machine called >smtpgate into thinking it's many machines for addressing reasons. (Political >reasons really) Is this OK? So far it works like a charm, but the keepers >of the DNS say I can't do it like this. I believe that multiple machine names (aka aliases) are not only OK but supported under DNS using the CNAME record. However, I'm not an expert on the arcane interactions between MX records and CNAME records and aliasing a mail machine might cause problems of which I am unaware. >Is it ok to have 1 IP for multiple hosts, when the actual host is *ONE* >machine? I'm defending my position on the grounds that A) it works, and >B) nothing seems to be affected by this 'trickery'. Can someone >prove/disprove my thinking??
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 94 16:13:54 From: zhao@crl.nmsu.edu (Z. Zhao) To: comp.protocols.tcp-ip,comp.protocols.ppp Subject: cslip-2.7 for sunos4.1.3
Hello, I am trying to implement cslip-2.7 on a sparc10/sunos4.1.3. I am confused about setting config file options for SLMTU. Should I set options SLMTU or options SLMTU=<N> or options SLMTU=<260> in the SYS_NAME file? '# config SYS_NAME' would say "options SLMTU=<N>" is a syntax error. SLMTU=<260> makes sense? ZiZi
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 16:50:01 From: waming@cuhk.hk (MING WA) To: comp.protocols.tcp-ip Subject: Announcing WGopher Version 2.3
Announcing Gopher for Windows Version 2.3
*****************************************************************
Gopher for Windows version 2.3 is a gopher client running on Microsoft
Windows 3.1 system with Windows Sockets (WINSOCK.PLL) v1.1 or later.
Features
1. Bookmarks
2. Text, Binary capability
3. Image capability (need to use external image viewer)
4. telnet,tn3270 capability (need to use external telnet
application)
5. Index capability
6. CSO capability
7. Attribute information (for Gopher+ item only)
8. Fonts selection
Installation
File is available at ftp server: /ftp.cuhk.hk
Directory: /pub/gopher/PC
File: wgoph23.zip
Use PKUNZIP.EXE to unpack the file wgoph23.zip. Follow the instructions
in README.TXT file.
Bugs, comments and suggestions
Please send any bugs, comments or suggestions to:
wa-ming@cuhk.hk
I would like to thank all the people who helped me to test the
WGopher version 2.2, particular those who sent bugs report and
made comments for the improvement. I am sorry if I did not reply
all mails you sent to me since I was busy sort out the problems
and try to speed up the new release.
-------------------------------------------------
Ming Wa
Computer Services Centre
The Chinese University of Hong Kong
E-mail: wa-ming@cuhk.hk
-------------------------------------------------
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 1994 12:27:38 GMT From: jfguilla@imag.fr (J-F Guillaud) To: comp.protocols.tcp-ip Subject: Where is the archive site for this group?
I have had a look to available articles and to the FAQ but I
haven't find the archive site for this group. Could someone help me to locate
the site where old articles are stored.
Thank you in advance
Jean-Francois
--
+---------------------------------------------------------+
--------------- | LGI / IMAG |
/ Jean-Francois \ | 46, av. Felix Viallet - 38031 Grenoble cedex 1 - France |
\ GUILLAUD / | Phone : +33 76 57 46 92 - Fax : +33 76 57 47 17 |
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 13:57:07 GMT From: landin@cherokee.nsuok.edu (Mark C. Landin) To: comp.protocols.tcp-ip Subject: Re: Multiple IP addrs for same hardware interface?
francisr@stupid.ucs.indiana.edu (Rob Francis) writes: >This is basically what I want to do. Not for nameservice, but I want >to gracefully eliminate a machine but its IP addr is fairly well >distributed. I actually got around the problem and now I'm just sort >of curious about the whole thing. So how did you get around it? I'm going to do the hardware shuffle in a month or two and would like any helpful anecdotes from people who've done it. -- *-----------------------------------------------------------------------------* * Mark C. Landin Northeastern St. Univ * * landin@cherokee.nsuok.edu Tahlequah, OK * * "Living in the pools, they soon forget about the sea" - Neil Peart, RUSH *
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 19:14:04 UNDEFINED From: jlewis@inorganic5.chem.ufl.edu (Jon Lewis) To: comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Questions regarding SLIP/PPP terminal server setups
NERDC (North East Regional Data Center - I think) has a dialup server setup here at UF. I think NERDC is part of or related to the state university system. They limit the use of slip/ppp by charging $0.01/min. My NERDC account, good on a few of the campus mainframes and the dialup server, is given $30/month. Online time and usage of the mainframes is billed to my account, and when the money runs out, I'm locked out until the money is replenished at the begining of the next month. They use Cisco hardware and software for the dialup server...thats all I know about that part. I've also setup my own slip server using KA9Q and SLIPLOG. SLIPLOG allows me to allot x minutes/day to each valid slip user. There must be something similar in function for the systems you'll be using. If you can do packet filtering, you might even be able to block people from telneting to MUDs. In article <CqqE1u.4Jq@oucsace.cs.ohiou.edu> rbarrett@oucsace.cs.ohiou.edu (Rich Barrette) writes: >The other pressing question was one of usage. How do we monitor >usage and decide who is doing real work? i.e. It would be highly >undesireable for someone to be logged into the server all of the >time while other people could do work. How do we monitor and decide >who is doing what? The subject can get complicated because we want >to offer this to students, some of which are CS and Engineering types >who can beat most simple monitoring systems by sending pings every >once in a while or use even more elaborate mechanisms. |------------------------------------------------------------------| | jlewis@inorganic5.chem.ufl.edu If the first address bounces | | let me know, and resend to the | | jlewis@chem.ufl.edu second address. | | If the second address bounces | | something's seriously wrong. | | | | Mime attachments are OK | |__________________________________________________________________|
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 1994 15:07:08 GMT From: dunnce@bcuxs2.bc.edu (Chad A Dunn) To: comp.sources.wanted,comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: PD ethernet analysis software?
If your on a Mac platform, there are several good analyzers. There's one called NetMinder from Neon software and also one called Etherpeek which is good for capturing packets and decoding them. Chad
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 16:12:13 GMT From: suzannei@nsa.bt.co.uk (Suzanne Irvine) To: comp.protocols.tcp-ip Subject: tcp/ip via sunlink dni
Hi, We are running two networks, one between the suns and another on the vax side. We have a sparc 10 (4.1.3) acting as a bridge which runs sunlink dni (7.0). Up to now mail has been quite happily passed from the suns to the vax, along with rlogin's etc. One of our users wishes to run tcp/ip applications from a dec pc via the suns. Firstly, is this possible and if so how do I go about it. Many thanks, -Suzanne Irvine
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 16:51:14 GMT From: jas@talking.COM (Jim Shankland) To: comp.protocols.tcp-ip Subject: Re: accept() core dump!
In article <1994May31.193949.14263@astph> jeff@astph (Jeff Martin) writes: >If we request an excessive number of client >socket connections, about 60, the accept call will not return >an error, but rather will dump a core. The stack is printed >below: > > malloc(0x408) [malloc.c] > _findbuf(0x4051b0) [flsbuf.c] > _filbuf(0x4051b0) [filbuf.c] > fgets(0x40462c,0x78,0x4051b0) [fgets.c] > rddev(0x4051b0,2,1,0) [socket.c] > socket(2,1,0) [socket.c] > accept(6,0x7ffffc3c,0x7ffffc38) [accept.c] > main(argc=1,argv=0x7ffffc6c) [db_root.c:82] > >It seem that the accept() call is not too accepting.... The problem is not accept() per se, but the fact that on your machine, accept() is evidently a library routine that ends up calling malloc(), and malloc() is dumping core while trying to allocate 1032 bytes. malloc() will do this if you've corrupted its data structures by scribbling on memory (e.g., by allocating x bytes in a previous call to malloc(), and then writing more than x bytes). Look for an unrelated bug in your program. This is the kind of problem that makes people thank their deity of choice that they have Purify. jas
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 1 Jun 1994 23:31:52 -0400 From: bacon@mtu.edu (Jeff Bacon) To: comp.protocols.tcp-ip Subject: Re: IP Loadsharing
given all this...let's suppose I want to use n>=2 slip or PPP links to provide a remote IP connection between two machines, unix-based. (let's assume sun for now) are there any specifc implementations of this I can get? -bacon -- = Jeff Bacon General Systems Hack, Michigan Technological Univ. = = bacon@mtu.edu ph-(906)487-2197 fax-(906)487-2782 DoD#2110 I'm the NRA = =I know that I would surely fall away, except the grace by which I'm saved...=
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 17:08:54 GMT From: jas@talking.COM (Jim Shankland) To: comp.protocols.tcp-ip Subject: SO_REUSEADDR, etc.
In article <1994May31.230644.11616@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>SO_REUSEADDR is indeed confusing.... [Followed by a predictably
>articulate description.]
So, my take on this is that SO_REUSEADDR is an unnecessary hack:
there is no reason you shouldn't be able to bind a server socket to
a port/address pair that is an endpoint of one or more connections
in the TIME_WAIT state, as long as you don't allow re-creation
of TCP connections ({lport, laddr, fport, faddr} quadruplets)
that are in the TIME_WAIT state. BSD-based implementations
are too restrictive when SO_REUSEADDR is not set, and (slightly)
too permissive when SO_REUSEADDR *is* set. Or have I missed
something?
>Now UDP on a system that supports multicasting (e.g., Solaris 2.x) does
>let you start multiple occurences of a server, all reading from the same
>local port. But that's another story ...
I don't understand why this should be coupled with multicast
capability. That is, it seems perfectly reasonable to allow
multiple servers to read from the same UDP port, even on a system
that does *not* allow multicasting (and very desirable in some
circumstances). Is there any reason other than happenstance
that this is available only on multicast-capable systems?
jas
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 18:29:53 GMT From: rbarrett@oucsace.cs.ohiou.edu (Rich Barrette) To: comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Questions regarding SLIP/PPP terminal server setups
Greetings, I have been involved in a project setting up a SLIP/PPP terminal server and offering these services to Windows and Mac users throughout campus. Right now we have a small exerimental group running smoothly. We presented our findings to the people who pay for this sort of thing and a couple of important questions came up: What are other Universities using as Hardware/Software for this sort of thing? What about public access companies? Right now we are running a Xyplex server hooked up to a Sun IPC and a rack of NEC modems. Aside from the lack of correct fallback and NO fallforward support on the NEC's things are running smoothly. We use Kerberos for our authentication which the Xyplex supports. I would appreciate any emails back with information similar to the above from any groups who are doing this same sort of thing, or offering similar services. The other pressing question was one of usage. How do we monitor usage and decide who is doing real work? i.e. It would be highly undesireable for someone to be logged into the server all of the time while other people could do work. How do we monitor and decide who is doing what? The subject can get complicated because we want to offer this to students, some of which are CS and Engineering types who can beat most simple monitoring systems by sending pings every once in a while or use even more elaborate mechanisms. Any ideas/comments/solutions/etc. greatly appreciated. Thanks for you time, -Rich -- Rich Barrette rbarrett@oucsace.cs.ohiou.edu
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 18:34:26 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: SO_REUSEADDR, etc.
> So, my take on this is that SO_REUSEADDR is an unnecessary hack:
> there is no reason you shouldn't be able to bind a server socket to
> a port/address pair that is an endpoint of one or more connections
> in the TIME_WAIT state, as long as you don't allow re-creation
> of TCP connections ({lport, laddr, fport, faddr} quadruplets)
> that are in the TIME_WAIT state. BSD-based implementations
> are too restrictive when SO_REUSEADDR is not set, and (slightly)
> too permissive when SO_REUSEADDR *is* set. Or have I missed
> something?
You are correct.
> > Now UDP on a system that supports multicasting (e.g., Solaris 2.x) does
> > let you start multiple occurences of a server, all reading from the same
> > local port. But that's another story ...
>
> I don't understand why this should be coupled with multicast
> capability. That is, it seems perfectly reasonable to allow
> multiple servers to read from the same UDP port, even on a system
> that does *not* allow multicasting (and very desirable in some
> circumstances). Is there any reason other than happenstance
> that this is available only on multicast-capable systems?
Right again. I think it's just because multicasting got people to
start thinking about multiple processes reading from the same UDP
port. Realize, however, that when multiple processes bind the
same UDP port, they all get copies of *only* broadcast or multicast
datagrams. Unicast datagrams still go to one process only. Which
one gets the unicast datagram is implementation-dependent if there
are multiple processes bound to the port.
Rich Stevens
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 19:15:57 GMT From: ysun@hotdog.bae.bellcore.com (Yi Sun) To: comp.unix.solaris,comp.protocols.tcp-ip Subject: Help on TLI
Does anyone know what the value 146 in the reason field of a call to t_rcvdis? Long: I am running 2.3 using TLI trying to connect to a server running on pyramid svr4 box. t_open was ok, failed in t_connect, so I did a t_look, and tells me I get a disconnect, so I do a t_rcvdis, the reason field was set to 146, but I cannot find it in any header files, any idea? In general, what options do you have when you get a disconnect on t_connect? thanx.
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 19:22:51 GMT From: nebrich@sed.psrw.com (Mark A. Nebrich) To: comp.protocols.tcp-ip Subject: TCP/IP Cleint/Server Timing Problem?
Hello netters,
I have a client/server timing problem that I hope someone can help me solve.
I am running on a Sun Sparc under SunOS 4.1.3. I have created two applications
(one server, one client) that communicate with one another over the sun
network (each process is running on a different machine).
The server is designed to notify connected clients when it (the server) dies.
Each client has the responsibility to close server connections and try to
reconnect. Once the server is restarted, it accepts client re-connections.
The problem is that when the server dies and each client disconnects and
immediately trys to reconnect, it connects to the dead server IP address.
This happens even though a new server has not yet started.
I think this occurs because the network has not yet had a chance to clear out
the old IP address on the client application host machine.
This obviously causes problems on client socket reads. If I put a sleep() call
in after the client application closes the old server socket (close()), this gives
the network time to clear itself out. This works but I don't think it's an elegant
solution for the problem (for example if the network is really busy, a sleep(5) may not
be enough time).
Can anyone tell me a more elegant way of determining if the net stats have been
updated so I can reconnect. I need to do this in software. Again, a sleep works but
the sleep time is not predicatable. Thanks in advance.
**********************************************************************************
----------
---- ---- Pacific-Sierra Research Corp.
-- -- Mark A. Nebrich
- - Phone: (703) 516-0223
---------- Email: nebrich@sed.psrw.com
------
----
--
**********************************************************************************
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 19:24:26 GMT From: ysun@hotdog.bae.bellcore.com (Yi Sun) To: comp.protocols.tcp-ip Subject: test program
Is there public test program to test tcp/ip between two machines using specified port number using TLI interface? thanx.
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 19:43:19 GMT From: mac@trantor.harris-atd.com (Mike McDonald) To: comp.protocols.tcp-ip Subject: Re: SO_REUSEADDR, etc.
In article <1994Jun1.183426.12830@noao.edu>, rstevens@noao.edu (W. Richard Stevens) writes: |> Right again. I think it's just because multicasting got people to |> start thinking about multiple processes reading from the same UDP |> port. Realize, however, that when multiple processes bind the |> same UDP port, they all get copies of *only* broadcast or multicast |> datagrams. Unicast datagrams still go to one process only. Which |> one gets the unicast datagram is implementation-dependent if there |> are multiple processes bound to the port. |> |> Rich Stevens Do you know what the reasoning for this behavior is? I've always modeled and implemented UDP so that every process bound to a port gets a copy of each packet. I guess I've been screwing it up. It seemed the only reasonable thing to me. I guess if you had multiple identical servers you wouldn't want them all to execute the same request. Mike McDonald Advanced Technology Dept. Harris Corp. Email: mac@trantor.harris-atd.com M.S. 16-1912 Voice: (407) 727-5060 P.O. Box 37 Fax: (407) 729-3363 Melbourne, Florida 32902
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 21:09:31 GMT From: art@acc.com (Art Berggreen) To: comp.protocols.tcp-ip Subject: Re: IP Loadsharing
In article <2s5gth$62s@hacgate2.hac.com> switt@triceratops.hac.com (Steve Witt) writes: >I've been reading RFC1131 describing the OSPF routing protocol and I notice >that it is capable of dicovering and using multiple, equal-cost routes to a >destination. This aroused my interest as I'm not sure how multiple routes >are "used" by IP. > >It is my understanding that a routing policy or protocol, like OSPF, executing >as a daemon (such as gated), initializes and updates the IP routing table that >IP uses to forward IP datagrams. The routes in the IP routing table, >indicate the next-hop router to which to forward IP datagrams for specific >destinations (either hosts or networks). If the routing protocol is >capable of discovering multiple routes to a destination host or network, is >IP capable of using this information? It would seem that the IP routing >table would need to have each route from the set of multiple routes to a >destination, inserted into the table and then IP would >need to have some method of using each route. My understanding of current >IP implementations (which is limited to the 4.3BSD from which SunOS was >developed) is that the IP routing algorithm first tries to find a host- >specific route for the datagram, then tries to find a network route for the >datagram, and then uses a default route (if it exists). It would seem that >if there were multiple entries in the IP routing table for a destination >network or host that the IP routing algorithm would match on the first one >found and forward the datagram accordingly and would not be able to make use >of multiple routes effectively. Perhaps I have a naive understanding of the >IP routing algorithm. > >Can IP (or particular implementations of IP) perform load sharing given a >routing policy that is capable of discovering useful multiple routes to a >destination? First, don't confuse protocol with implementation. Last time I looked at BSD Unix, it was not capable of maintaining multiple equal cost routes in the kernel's routing table. But since the vast majority of Unix machines are singly homed, with typically one or two routers on their LAN, it's not a problem. Many routers can maintain, and use, multiple equal cost routes. These routers will usually load share across the available paths. It makes more sense with routing protocols where the metrics have some relationship to link capacity (such as OSPF), than with routing protocols which deal purely in hop counts (such as RIP). Art
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 22:14:58 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.unix.solaris,comp.protocols.tcp-ip Subject: Re: Help on TLI
> Does anyone know what the value 146 in the reason field of a call to t_rcvdis?
> I am running 2.3 using TLI trying to connect to a server running on pyramid
> svr4 box. t_open was ok, failed in t_connect, so I did a t_look, and tells me
> I get a disconnect, so I do a t_rcvdis, the reason field was set to 146, but I
> cannot find it in any header files, any idea?
% grep 146 /usr/include/sys/errno.h
#define ECONNREFUSED 146 /* Connection refused */
Looks like you got an RST in response to your SYN. Perhaps the server
process wasn't started, or you have the wrong port?
Rich Stevens
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Wed, 1 Jun 1994 22:29:00 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: SO_REUSEADDR, etc.
>|> Right again. I think it's just because multicasting got people to >|> start thinking about multiple processes reading from the same UDP >|> port. Realize, however, that when multiple processes bind the >|> same UDP port, they all get copies of *only* broadcast or multicast >|> datagrams. Unicast datagrams still go to one process only. Which >|> one gets the unicast datagram is implementation-dependent if there >|> are multiple processes bound to the port. > > Do you know what the reasoning for this behavior is? I've always modeled and >implemented UDP so that every process bound to a port gets a copy of each packet. I don't know. As I recall, the first system to let you bind multiple processes to the same UDP port was the Stanford multicasting code from Steve Deering, circa 1989. In his README file dated June 24, 1989: "More than one process may bind to the same SOCK_DGRAM UDP port if the bind() is preceded by: int one = 1; setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &one, sizeof(one)) In this case, every incoming multicast or broadcast UDP datagram destined to the shared port is delivered to all sockets bound to the port. For backwards compatibility reasons, THIS DOES NOT APPLY TO INCOMING UNICAST DATAGRAMS -- unicast datagrams are never delivered to more than one socket, regardless of how many sockets are bound to the datagram's destination port." Rich Stevens
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1994 09:08:03 -0400 From: alfredh806@aol.com (AlfredH806) To: comp.protocols.tcp-ip Subject: Re: WINQVTNET Users
In article <358@trotter.UUCP>, ae6244@leibniz.math.usma.edu (MARKERT ERICH L. MR.) writes: Re: WinQVT/Net Printing I am trying to send the output to the local printer attached to the workstation running WinQVT/Net. Any ideas? Thanks!
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1994 09:12:18 -0400 From: brain@msen.com (Jim Brain) To: comp.protocols.tcp-ip Subject: Questions about tcp-ip not in FAQ.
Being somewhat new to to TCP-IP programming, I want to ask those in the know a few questions: In APPC, most implementations provide a program launch capability similar to inetd server capabilities. Can someone detail how inetd works? If it uses RAW sockets to do special stuff, can someone point me to a text that describes what special functions that tcp-ip has to offer? I have gotten spoiled with other protocols abilities to post my semaphore whenever something is received from the channel. I realize that standard sockets does not provide this, but does anyone have an extension that does this? (MS/IBM/...) Since my first implementation is for OS/2, followed by UNIX, I would like those who have done the same answer me. Is there some sample code available on the net that I can compile and play with to see how sockets code is written? Jim Brain. -- Jim Brain, Embedded Systems Designer, Brain Innovations. brain@msen.com Dabbling in VR, Old Commodore Computers, and Good Times! "The above views DO reflect my employer, since I am my employer" - Jim Brain
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1994 09:17:17 -0400 From: acinader@panix.com (Arthur Cinader) To: panix.questions,panix.internet.slip,panix.internet.ppp,comp.protocols.tcp-ip Subject: Mosaic conflict?
I have mosaic 1.03 on my Quadra 800. When I launch it, I get "Unable to connect to remote host" in the status bar and "text has not been loaded" in the text box. My home page is set to: http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/NCSAMosaicHome.html and I have tried loading other url's such as MTV.com to make sure that my problem is not just an overloaded home page. I am confident that this is not the problem. My guess is that tcp packets are not moving from mosaic to MACtcp and vica versa. I have properly configured computers to run mosaic before, but I cannot figure out what is wrong this time around. Two things come to mind. 1. I am know using Intercom TCP Conect II as a telnet, ftp client. Is anybody using Connect II and Mosaic suc cessfully? 2. My mac is on an ethertalk network (however, I have gotten mosaic to work on such a configured computer before.) Any Ideas, reccomendations? Anybpdy know the developers address so I can mail them a copy of this letter? ACjr.
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 02:56:35 GMT From: bleys@vpnet.chi.il.us (Bleys Ahrens) To: comp.protocols.tcp-ip Subject: Re: DNS and OpenView
Richard E. Blair (rblair@cabell.vcu.edu) wrote: : Is anyone out there running HP OpenView on a Name Server? We are : running OpenView 3.2 on an HP 715/50 running HP-UX 9.01. Whenever : I start named and then run OpenView, I get the error message "ovw: : unable to resolve "hostname" to get a license." The name server : itself work fine, and I believe it's configured properly. What I : don't know is exactly how OpenView attempts to resolve a hostname. : Any suggestions would be greatly appreciated. : Richard Blair : rblair@cabell.vcu.edu I suspect that what you are seeing is due to some entries in an Openview registration file. Running DNS is probably changing your hostname to a fully qualified domain name which does not correspond to the info that was entered when you installed and configured the product. (I have seen the same thing several times with IBM's Openview derivative, Netview/6000. Thanks. Bleys -- ========================================================================== = Bleys Ahrens Chicago, IL = = VPNET/Public Access Usenet = = Information gains value when shared... bleys@vpnet.chi.il.us = ==========================================================================
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 03:49:30 GMT From: csmoko@relay.nswc.navy.mil (Chuck Smoko - E81) To: comp.protocols.tcp-ip Subject: Re: Multiple IP addrs for same hardware interface?
In article <1994Jun1.135707.10535@cherokee.nsuok.edu> landin@cherokee.nsuok.edu (Mark C. Landin) writes:
>
>So how did you get around it? I'm going to do the hardware shuffle in a
>month or two and would like any helpful anecdotes from people who've
>done it.
I have some code allows the multiple addresses per interface. It
is done with what is called a virtual interface. I did not write the
code (included), but I have ported it Sunos.
chuck smoko
PS: If you want the sun mods, please email to csmoko@nswc.navy.mil. Below
is a old post to this group.
-------------------------------- SNIP ---------------------------------
I have a solution than might suit you. For my doctoral work (there's
a paper about it in this year's ('91) SIGCOMM, also available for
anonymous FTP from cs.columbia.edu:/pub/ji/sigcomm*.ps.Z), I've
developed what I call the "Virtual Interface" (VIF). To the networking
code, it looks like an interface. It gets ifattach()ed when you open
the /dev/vif* device, and then you can ifconfig it as you like. It
does not have an if_input procedure; it only has an if_output. Packets
that it receives (from higher-level protocols) which have its
IP address, it simply loops back (like any well-behaved if driver).
Packets that it receives that are destined for some other address, it
encapsulates in an encapsulation protocol I call IPIP (IP-within-IP,
protocol number IPPROTO_IPIP == 94), and sends it to another machine
that groks that encapsulation protocol. This feature you won't need,
but here's how to have multiple IP addresses on a machine with a
single real interface:
Let's say your primary interface's IP address is 198.3.2.1, and you
also want it to respond to addresses 198.4.3.2 and 198.5.4.3 (note
that these are three distinct class C addresses in three distinct
class C nets). Here are the ifconfigs:
ifconfig le0 198.3.2.1 up -trailers # config primary interface
ifconfig vif0 198.4.3.2 up # config first virtual interface
route delete net 198.4.3 198.4.3.2 # delete spurious route
route add host 198.4.3.2 198.4.3.2 0 # add route for this i/f
ifconfig vif1 198.5.4.3 up # config second virtual interface
route delete net 198.5.4 198.5.4.3 # delete spurious route
route add host 198.5.4.3 198.5.4.3 0 # add route for this i/f
The route deletes are needed because the ifconfig creates a default
route to the interface's network, which can cause problems; all that's
needed is the (host) route to the interface's address.
Now, get le0's ethernet address (say, 8:0:20:3:2:1), and add the
following static ARP entries:
arp -s 198.4.3.2 8:0:20:3:2:1 pub
arp -s 198.5.4.3 8:0:20:3:2:1 pub
This will cause any ARP requests for the VIF addresses to be replied
with your machine's ethernet address.
Now, make sure your default route is to your segment's gateway,
throught the real interface. FInally, make sure your routers and/or
hosts on the same segment as yours know that 198.4.3.2 and 198.5.4.3
are on that cable.
Here's what you've accomplished.
ARP requests for any of your host's addresses will be replied to with
the host's ethernet address (the real one, because that's what it is,
the virtual ones because of the public static arp entries). Packets
reaching your host with any of these addresses will be accepted by the
ip_input routine because they match the address of one of the host's
interfaces. Packets leaving your host can have any of its addresses
(real and virtual).
The code for vif follows. To use it, put the stuff in netinet/if_vif.c
and netinet/if_vif.h, configure your kernel with the number of
virtual interfaces you want using a line like:
pseudo-device vif4 # Virtual IP interface
in your configuration file, and two lines like
netinet/if_vif.c optional vif device-driver
netinet/if_vif.hc optional vif device-driver
in the files file. Also, add the appropriate entries in conf.c, so
that you can access the if_attach() routine when you open the device:
------------------------in conf.c------------------------------------------
add this in the appropriate place in the headers of conf.c:
--------------------
#include "vif.h"
#if NVIF > 0
int vifopen(), vifclose(), vifread(), vifwrite(), vifselect(), vifioctl();
#else
#define vifopen nodev
#define vifclose nodev
#define vifread nodev
#define vifwrite nodev
#define vifselect nodev
#define vifioctl nodev
#endif
--------------------
then, way down in the definition for cdevsw[]:
--------------------
vifopen, vifclose, vifread, vifwrite, /*31*/
vifioctl, nodev, nodev, 0,
vifselect, nodev,
--------------------
Make sure you remember the correct major device number!
------------------------in conf.c------------------------------------------
Finally, here's the code. It has the tunneling pieces removed (you
need more code to use that anyway), and it comes from a Mach 2.6
kernel; it should compile on any berkeley-derived unix with minor
changes (most likely only in the includes).
---------------------netinet/if_vif.h--------------------------------------
typedef struct
{
struct ifnet vif_if;
struct ifnet *vif_sif; /* slave interface */
int vif_flags;
} vif_softc_t;
#define VIFMTU (1024+512)
---------------------------------------------------------------------------
and
---------------------netinet/if_vif.h--------------------------------------
/*
* HISTORY
* $Log:$
*/
/*
* $Header:$
*
* Virtual IP interface module.
*/
#include <multicast.h>
#include "param.h"
#include "systm.h"
#include "mbuf.h"
#include "socket.h"
#include "errno.h"
#include "ioctl.h"
#include "../net/if.h"
#include "../net/netisr.h"
#include "../net/route.h"
#ifndef MACH
#include "../machine/mtpr.h"
#endif
#ifdef INET
#include "../netinet/in.h"
#include "../netinet/in_systm.h"
#include "../netinet/in_var.h"
#include "../netinet/ip.h"
#endif
#ifdef NS
#include "../netns/ns.h"
#include "../netns/ns_if.h"
#endif
#include "in_pcb.h"
#include "ip_var.h"
#include "ipip.h"
#include "ipip_var.h"
#include "micp.h"
#include "micp_var.h"
#include "if_vif.h"
#include "vif.h"
vif_softc_t vif_softc[NVIF];
int vifs_inited = 0;
int vifoutput(), vififioctl();
vifattach()
{
register int i;
register struct ifnet *ifp;
for (i=0; i<NVIF; i++)
{
ifp = &vif_softc[i].vif_if;
ifp->if_name = "vif";
ifp->if_unit = i;
ifp->if_mtu = VIFMTU;
#if MULTICAST
ifp->if_flags = IFF_MULTICAST | IFF_NOARP;
#else MULTICAST
ifp->if_flags = IFF_NOARP;
#endif MULTICAST
ifp->if_ioctl = vififioctl;
ifp->if_output = vifoutput;
if_attach(ifp);
}
}
vifopen(dev, flag)
int dev, flag;
{
int unit;
if (!vifs_inited)
{
vifattach();
vifs_inited = 1;
printf("vif initialized\n");
}
unit = minor(dev);
if ((unit < 0) || (unit >= NVIF))
{
return ENXIO;
}
return 0;
}
vifclose(dev, flag)
int dev, flag;
{
return 0;
}
vifread()
{
return ENXIO;
}
vifwrite()
{
return ENXIO;
}
vifselect()
{
return ENXIO;
}
vifoutput(ifp, m0, dst)
struct ifnet *ifp;
register struct mbuf *m0;
struct sockaddr *dst;
{
int s;
register struct ifqueue *ifq;
struct mbuf *m;
struct sockaddr_in *din;
if (dst->sa_family != AF_INET)
{
printf("%s%d: can't handle af%d\n",
ifp->if_name, ifp->if_unit,
dst->sa_family);
m_freem(m0);
return (EAFNOSUPPORT);
}
din = (struct sockaddr_in *)dst;
if (din->sin_addr.s_addr == IA_SIN(ifp->if_addrlist)->sin_addr.s_addr)
{
printf("%s%d: looping\n", ifp->if_name, ifp->if_unit);
/*
* Place interface pointer before the data
* for the receiving protocol.
*/
if (m0->m_off <= MMAXOFF &&
m0->m_off >= MMINOFF + sizeof(struct ifnet *)) {
m0->m_off -= sizeof(struct ifnet *);
m0->m_len += sizeof(struct ifnet *);
} else {
MGET(m, M_DONTWAIT, MT_HEADER);
if (m == (struct mbuf *)0)
return (ENOBUFS);
m->m_off = MMINOFF;
m->m_len = sizeof(struct ifnet *);
m->m_next = m0;
m0 = m;
}
*(mtod(m0, struct ifnet **)) = ifp;
s = splimp();
ifp->if_opackets++;
ifq = &ipintrq;
if (IF_QFULL(ifq)) {
IF_DROP(ifq);
m_freem(m0);
splx(s);
return (ENOBUFS);
}
IF_ENQUEUE(ifq, m0);
schednetisr(NETISR_IP);
ifp->if_ipackets++;
splx(s);
return (0);
}
return EHOSTUNREACH;
}
/*
* Process an ioctl request.
*/
/* ARGSUSED */
vififioctl(ifp, cmd, data)
register struct ifnet *ifp;
int cmd;
caddr_t data;
{
int error = 0;
switch (cmd) {
case SIOCSIFADDR:
ifp->if_flags |= IFF_UP;
/*
* Everything else is done at a higher level.
*/
break;
default:
error = EINVAL;
}
return (error);
}
vifioctl(dev, cmd, arg, mode)
dev_t dev;
int cmd;
caddr_t arg;
int mode;
{
int unit;
unit = minor(dev);
if ((unit < 0) || (unit >= NVIF))
return ENXIO;
return EINVAL;
}
----------------------------------------------------------------------------
To use it, compile your kernel, and reboot. Then create the vif
device:
# mknod /dev/vif c 31 0
(or whatever major number it ended up being), and echo something into
it:
# echo > /dev/vif
This will cause the device to be opened, which will if_attach the
interfaces. If you feel like playing with the code, you may want to
kmem_alloc() the vif_softc structrure at open time, and use the minor
number of the device to tell it how many interfaces to create.
Now you can go ahead and ifconfig etc.
I'll be happy to answer minor questions, and hear about success and
failure stories, but I cannot help you if you don't already know how
to hack kernels.
Good luck!
/ji
In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 05:51:56 GMT From: jas@talking.COM (Jim Shankland) To: comp.protocols.tcp-ip Subject: Multiple processes bound to same UDP port (was Re: SO_REUSEADDR, etc.)
In article <1994Jun1.183426.12830@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes: >Realize, however, that when multiple processes bind the >same UDP port, they all get copies of *only* broadcast or multicast >datagrams. Unicast datagrams still go to one process only. Which >one gets the unicast datagram is implementation-dependent if there >are multiple processes bound to the port. Which is, of course, exactly what you sometimes want: e.g., when you have a cluster of server processes reading service requests as UDP datagrams, doing some work, and returning to the well for the next request. It doesn't matter which server gets the datagram, as long as each datagram goes to exactly one server .... jas
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1994 18:27:51 -0700 From: lstowell@pyrnova.mis.pyramid.com (Lon Stowell) To: comp.protocols.tcp-ip Subject: Re: comp.protocols.tcp-ip
In article <2slml4$o1p@ns9000.furman.edu> mathews@ns9000.furman.edu (E. Owen Mathews) writes: > >I'm interested in comprehensive documentation of TCP/IP. >I need to know details about the hardware level, the >driver level, and the API level. Are there any good >resources that you could recommend? I need to start >from the very basic level, but I need some in-depth >information as well. Any help would be appreciated. > I'd start with the Comer manuals on TCP/IP. Volume 1 which is the protocols themselves, then Volume 2 which gives implementation issues (and sample code). The Richard Stevens Unix Network Programming is a must if you are doing this on Unix.
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 07:33:43 GMT From: cpm@uniplex.co.uk (Chris P Murray) To: comp.protocols.tcp-ip Subject: SO_REUSEADDR equivalent in TLI?
I'm having problems getting a server that uses 'TLI' to rebind after a client has crashed and left a previous connection in FIN_WAIT2. The socket implementation is fine (I use the SO_REUSEADDR option). Does anyone know if there is an equivalent option in TLI?!?? I've tried to use the 't_optmgmt()' call but with no luck - the documentation doesn't explain its parameters very well. There is a "TP_REUSEADDR" per-protocol option that, allegedly, can be set/got via t_optmgmt(). Has anyone got this or a REUSEADDR equivalent to work under the TLI interface?? -Chris.
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 14:54:33 From: CAMARA@novell.wd.cubic.com (Raland Camara) To: comp.protocols.tcp-ip Subject: hp-ux startup files and hp-vue
All,
I have been encountering a handful of problems surrounding some of the
startup files under HP-UX and HP-VUE. In particular,
1. When telneting into my HP-UX system, my ~/.kshrc file is not sourced
and only ~/.profile is run. How does one insure that ~/.kshrc is
sourced upon login? When a user has his default shell (/bin/ksh)
defined in the /etc/passwd file as shown below, shouldn't the .kshrc
file in his home directory automatically get sourced upon login?
Note: My entry in the /etc/passwd file is as follows:
raland:*:201:200:Raland Camara,,,:/users/raland:/bin/ksh
2. Where can I obtain a set of default (i.e. fairly generic)
xwindows/window manager/vue resource files to support my xterminal?
(e.g. .Xsession, .Xstartup, etc.)
My xterminal is: HP ENVIZEX A SERIES Model C2731A Monitor HP A2094A.
3. My .vueprofile is not executed when logining in under VUE. How
can I change this such that my .vueprofile DOES execute when logging
in under VUE? Also, how can I have my shell startup files get
sourced when bringing up a hpterm by clicking on the terminal emulator
icon on the front panel?
I determined that my .vueprofile was not being executed because
of the following test. I defined an environment variable and
exported it in my .vueprofile and it does not show up in my
environment.
in ~/.vueprofile:
TESTVAR=true; export TESTVAR;
.
.
.
from an hpterm shell prompt:
$ env | grep TESTVAR
$
Any help or insight you might be able to provide will be greatly
appreciated.
Thanks in advance,
Raland
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1994 12:38:58 GMT From: nirad@cs.uq.oz.au (Nirad Sharma) To: comp.dcom.lans,comp.protocols.tcp-ip Subject: Fault / Performance degradation diagnosis books / articles
Can anyone recommend any detailed work dealing with fault diagnosis on LANs (and WANs, if available) ? I'm particularly after something that deals with OSI and/or TCP/IP. I'm after this material to round out my own experience to developing some model-driven knowledge-based diagnosis systems that apply some research that I am undertaking to some network diagnosis / reconfiguration scenarios. -- Nirad Sharma Computer Science, University of Queensland
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 17:39:58 UNDEFINED From: treynold@fred.lasalle.edu (Tommi) To: comp.protocols.tcp-ip Subject: Re: Assign IP address to person or machine?
In article <1994Jun2.182805.28009@nb.rockwell.com> mcfowler@sol.rockwell.com (Mark C. Fowler) writes: >From: mcfowler@sol.rockwell.com (Mark C. Fowler) >Subject: Assign IP address to person or machine? >Keywords: IP, address, person, machine >Date: Thu, 2 Jun 1994 18:28:05 GMT >There's a situation where PC users (running DOS and MS-Windows) that >use Banyan Vines download TCP/IP from the Vines server. The version >of TCP/IP that they are using needs an .INI file that they get from >their personal directory on their Vines server. The .INI file >contains their IP address. > This has led to assigning IP addresses to people instead of >machines. My gut reaction is that this may cause problems, but I >can't quite come up with good arguments as to why. I'm wondering how >others feel about the assignment of IP addresses to people instead of >machines. Is it a good idea? Bad idea? Does it really matter? What >are the security issues, if any? What are the network management and >system administration issues? If this is the case, hope that your people stay on the same subnet all the time. For example, I'd hate to give people an address that was relative to their office wired on the 20 segment (just for example :) and then have them use Bob's office downstairs, which is on the 12 segment...... Are your users always going to be on the same machine is what it comes down to, I suppose. If, for example, Joe Average is assigned 200.200.200.200 and goes about using that address on several machines, what happens if during your management routine one day you discover that the network is overloaded due to a bad transmitter in 200.200.200.200? (Sure, you should be able to look up an ethernet address too, which you should in turn be able to track down, but...) Or am I reading this all wrong? :) Hope this helps.... --- Tommi treynold@fred.lasalle.edu The above are my thoughts; if you don't like them, don't read them!
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 14:36:34 GMT From: vjs@calcite.rhyolite.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: IP Loadsharing
In article <2sjjr8$h7q@minerva.doe> bacon@mtu.edu (Jeff Bacon) writes: >given all this...let's suppose I want to use n>=2 slip or PPP links >to provide a remote IP connection between two machines, unix-based. >(let's assume sun for now) >are there any specifc implementations of this I can get? I know of one, but it's binary only for workstations other than Sun's. More important, while I've been pushing that "Brute Force and Ignorance" style of multilinking in the IETF PPP mailing list for years, even I agree that the forthcoming PPP multi-link protocol is a much better way do do things. Even fairly recent BSD TCP/IP gets confused and doesn't go as fast as it should when given re-ordered segments by such a simplistic scheme. Vernon Schryver vjs@rhyolite.com
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1994 14:37:06 GMT From: longm@firnvx.firn.edu (Michael Long) To: comp.protocols.tcp-ip Subject: DNS freeware for DOS/Windows?
I am looking for a DNS server freeware package for DOS or Windows if anyone knows where I can find one. Thanks Mike... ***************************************************************************** Michael Long - Sr. Systems Programmer Florida State University/Florida Information Resource Network/Florida D.O.E. E-mail: longm@firnvx.firn.edu Phone: (904)487-0911 *****************************************************************************
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1994 14:49:11 GMT From: longm@firnvx.firn.edu (Michael Long) To: comp.protocols.tcp-ip Subject: Looking for Whois Client/Server package?
I am looking for a Whois Client or Server application for Windows. Hopefully freeware. If anyone knows where I can ftp it from, it would be greatly appreciated. Thanks Mike... ***************************************************************************** Michael Long - Sr. Systems Programmer Florida State University/Florida Information Resource Network/Florida D.O.E. E-mail: longm@firnvx.firn.edu Phone: (904)487-0911 *****************************************************************************
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 15:39:32 GMT From: johannes@titan.westfalen.de (Johannes Stille) To: comp.protocols.tcp-ip Subject: Re: variable subnetting AND static routing, no OSPF .. ?
In article <sej.770324974@interaccess> sej@flowbee.interaccess.com (Stephen Johnson) writes: [...] >Yes, static routing will work with variable subnetting. However, it >may be possible to create a network subnetting scheme that would be >impossible route through (static or otherwise). Keep it simple and >you shouldn't have any problems (famous last words :) ). [...] I can see (or rather: have encountered) another problem with variable subnetting: How do you recognize directed broadcasts? The IP implementation I use doesn't allow the use of broadcast addresses in certain situations. This makes sense to prevent packet storms e.g. with directed "ping" broadcasts to another subnetwork. (In this case, the restriction can be lifted with a socket flag if you really want to do this.) With variable subnetting, I don't see how it could be possible to recognize directed broadcasts. Example: I have a class B network and a machine on a subnet with mask 255.255.255.192. Now I want to send to machine x.y.10.255, which is on a subnet with mask 255.255.248.0, and thus a legal address. But for me, this address lokks like a directed broadcast to a subnetwork x.y.10.192. The same problem exists if some machine tries to connect to me with an address that looks like a subnetwork broadcast address. AFAIK, e.g. a TCP connection request from a directed broadcast address would be discarded. Is there a common solution to this problem, is it perhaps even discussed in some RFC? Any comments and pointers to information available on the net are welcome. Johannes
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 15:41:47 GMT From: atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson) To: comp.protocols.tcp-ip Subject: Re: long delay TCP
In article <2sfeba$m5b@brachio.zrz.TU-Berlin.DE> rene@dhzb.de (Rene Simon) writes: >Is there an implementation of a TCP for "long delay" connections like >RFC1323 ? >I need it for SunOS and Solaris. I believe that Solaris 2.x already implements RFC-1323. For SunOS 4.1.x, _experienced_ kernel hackers can put Tom Skibo's TCP implementation (includes RFC-1323) into the kernel. Novices should not attempt this. Ran atkinson@itd.nrl.navy.mil --
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 16:18:13 GMT From: cisml@world.std.com (Marty Lebowitz) To: comp.protocols.tcp-ip Subject: Need help in filling some openings!
Hi, We currently are conducting a search for people (contract and direct) with expertise in network protocol software for WAN's. Any help you can offer in referring somone, would be much appreciated! Marty #6024 - Network Consultants (2) - Network Protocols Serve as internal expert on performance of protocols across WAN's, working with customers, providing analytical analysis of performance within given configuration. Ability to recommend new products and new service offerings and help specify them. Act as mentor to junior engineers. Requries 4+ years industry experience with specialties in TCP/IP, ATM, SNA, APPN, FRAME RELAY, Windowing, hardware/software interfacing.. Location: (OK/TX). Other intermediate and senior level openings exists both locally and nationally. For immediate confidential phone interview, fax/email resume AND call Marty Lebowitz, President Computer Interactive Services, Inc. Tel: 617- 232-8300 Fax: 617- 232-6240 # # # #
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 16:48:08 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: long delay TCP
> > Is there an implementation of a TCP for "long delay" connections like > > RFC1323 ? > > I need it for SunOS and Solaris. > > I believe that Solaris 2.x already implements RFC-1323. Nope. Someone at Sun told me it probably wouldn't make Solaris 2.4 either. Anyone at Sun care to comment? > For SunOS 4.1.x, _experienced_ kernel hackers can put Tom Skibo's TCP > implementation (includes RFC-1323) into the kernel. I think you can buy it from Sun as some kind of special request feature. Rich Stevens
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Jun 94 01:13:38 -0500 From: baldwinl@delphi.com To: comp.protocols.tcp-ip Subject: Telnet response time after packet drop?
I'm currently troubleshooting a Telnet response time problem on a very heavily u utilized token ring (50%+). With a Sniffer, it seems to take nearly two seconds for TCP to recover from a single dropped packet. After reading up on TCP retransmission algorithms it almost seems like this is normal. If I understand it correctly TCP doesn't retransmit until after receiving 3 duplicate ACKs (packet out of order). The configuration is an PC running OS/2 with IBM's IP stack communicating with a Sun Sparc 1000. Also can anyone suggest further references on TCP retransmission algorithms? Thanks.
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 17:40:20 GMT From: atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson) To: comp.protocols.tcp-ip Subject: Re: long delay TCP
>> > Is there an implementation of a TCP for "long delay" connections like >> > RFC1323 ? >> > I need it for SunOS and Solaris. >> >> I believe that Solaris 2.x already implements RFC-1323. > >Nope. Someone at Sun told me it probably wouldn't make Solaris 2.4 either. >Anyone at Sun care to comment? I talked with a developer inside Sun who said they had already done it for Solaris; I wasn't blindly speculating. Now I wonder if it is a "special" for Solaris rather than in the standard release. It would help if Sun would comment on the record about this. Ran atkinson@itd.nrl.navy.mil --
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 17:58:38 GMT From: jimc@jts.jts.com (Jim Carroll ) To: comp.protocols.tcp-ip,comp.sys.sun.admin Subject: how to set up RARP/BOOTP clients?
Sorry if this is a repeat posting, but our nntpd was acting weird lately. Environment: - PCs (MS-DOS & MS-Windows running LWP) - Suns running SunOS 4.1.2 and 4.1.3 - misc (a Solaris 2 box, a Pyramid, an HP) - NIS is being run Goal: To be able to set up a centrally manageable environment, as far as IP addressing is concerned. I'm looking for a way to set up our LAN so that all PCs and (almost) all Suns and as many of the none-of-the-above systems so that I can manage all IP addresses from one (or two, or three) places. I currently have BOOTP running on my Sun server, probably courtesy of installing HP JetDirect cards. In the meantime, I've added as many hosts as possible to /etc/ethers (and /etc/hosts, of course) with the hope that I could get one of these 2 technologies to do what I want. To be more precise, the PCs successfully use RARP to get their IP addresses. The Suns have them configured on the local disks. I'd like to be able to learn how to either set up the non-server Suns (and misc.) to use RARP on boot-up, or to set all non-server nodes to use BOOTP on boot-up. The latter will require a sample config entry for /etc/bootptab for both a PC and a Sun, as well as a pointer to an RFC, if possible. Hints on how to set up the HP/Pyramid/Solaris2 systems to use RARP/BOOTP on boot-up would be appreciated, too. As usual, beg/plead/whimper/grovel yahda yahda yahda. :-) Email answers preferred, as I don't know if or when I'll have the next opportunity to read these newsgroups. Thanks. -- -- * Jim Carroll * jimc@jts.com * JTS Systems Corp., Toronto, Ont. * | bumper sticker seen: " My other car is a Klingon Battle Cruiser" |
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Thu, 2 Jun 1994 18:28:05 GMT From: mcfowler@sol.rockwell.com (Mark C. Fowler) To: comp.protocols.tcp-ip Subject: Assign IP address to person or machine?
There's a situation where PC users (running DOS and MS-Windows) that use Banyan Vines download TCP/IP from the Vines server. The version of TCP/IP that they are using needs an .INI file that they get from their personal directory on their Vines server. The .INI file contains their IP address. This has led to assigning IP addresses to people instead of machines. My gut reaction is that this may cause problems, but I can't quite come up with good arguments as to why. I'm wondering how others feel about the assignment of IP addresses to people instead of machines. Is it a good idea? Bad idea? Does it really matter? What are the security issues, if any? What are the network management and system administration issues? Mark Fowler
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1994 19:17:41 GMT From: balenson@tis.com (David M. Balenson) To: alt.privacy,alt.security,alt.security.pgp,alt.security.ripem,comp.protocols.kerberos,comp.protocols.tcp-ip,comp.security.misc,comp.security.unix,ieee.announce,sci.crypt Subject: Call for Papers - 1995 ISOC Symp. on Netw. and Distr. Sys. Security
CALL FOR PAPERS
The Internet Society Symposium on
Network and Distributed System Security
16-17 February 1995, Catamaran Hotel, San Diego, California
GOAL: The symposium will bring together people who are building
software and/or hardware to provide network and distributed system
security services. The symposium is intended for those interested in
the more practical aspects of network and distributed system security,
focusing on actual system design and implementation, rather than in
theory. We hope to foster the exchange of technical information that
will encourage and enable the Internet community to apply, deploy and
advance the state of the available security technology. Symposium
proceedings will be published by the Internet Society. Topics for the
symposium include, but are not limited to, the following:
* Design and implementation of security services -- access control,
authentication, availability, confidentiality, integrity, and
non-repudiation.
* Design and implementation of security mechanisms and support
services -- encipherment, authentication, and key management
systems, including fair cryptography -- access control,
authorization and audit systems -- and intrusion detection systems.
* Requirements and designs for securing distributed applications
and network functions -- message handling, file transport, remote
file access, directories, time synchronization, interactive
sessions, remote data base management and access, routing, voice and
video multicast and conferencing, news groups, network management,
boot services, mobile computing, and remote I/O.
* Requirements and designs for securing networked information
resources and tools -- Archie servers, the Wide Area Information
Servers (WAIS), the Internet Gopher, and the WorldWide Web (WWW).
* Design and implementation of measures for controlling internetwork
communication and services in a coherent manner -- firewalls, packet
filters, application gateways, and user/host authentication
schemes.
* Requirements and designs for telecommunications security especially
for emerging technologies -- very large systems like the
international Internet, high-speed systems like the gigabit
testbeds, wireless systems, and personal communication systems.
* Special issues and problems in security architecture, such as
interplay between security goals and other goals -- efficiency,
reliability, interoperability, resource sharing, and cost.
GENERAL CHAIR:
Jim Ellis, CERT Coordination Center
PROGRAM CHAIRS:
David Balenson, Trusted Information Systems
Rob Shirey, The MITRE Corporation
PROGRAM COMMITTEE:
Tom Berson, Anagram Laboratories
Matt Bishop, University of California at Davis
Ravi Ganesan, Bell Atlantic
Burt Kaliski, RSA Laboratories
Steve Kent, BBN Communications
Paul Lambert, Motorola
John Linn, OpenVision Technologies
Clifford Neuman, Information Sciences Institute
Hilarie Orman, University of Arizona
Michael Roe, Cambridge University (UK)
Rob Rosenthal, U.S. National Institute of Standards and Technology
Jeff Schiller, Massachusetts Institute of Technology
Mike St. Johns, Advanced Research Projects Agency
Peter Yee, U.S. National Aeronautics and Space Administration
Roberto Zamparo, Telia Research (Sweden)
SUBMISSIONS: The committee invites both technical papers and
proposals for panel discussions on technical and other topics of
general interest. Technical papers should be 10-20 pages in length.
Panel proposals should be two pages in length, and should describe the
panel topic, name the panel chair, explain the format of the panel, and
list three to four potential panelists. The technical papers will
appear in the proceedings. Panel chairs and panelists will have the
option of having written statements appear in the proceedings.
All submissions should contain a separate title page which includes the
type of submission (paper or panel), the title or topic, the names of
the author(s), organizational affiliation(s), telephone and FAX
numbers, postal addresses, Internet electronic mail addresses, and the
point of contact, if more than one author. Since the review process
will be anonymous, the author's names, affiliations and other
information should appear only on the separate title page.
Deadline for paper submission: August 15, 1994
Notification sent to authors by: October 17, 1994
Deadline for camera-ready copy: November 15, 1994
Submissions must be made by 15 August 1994. Submissions should be made
via electronic mail. Submissions may be in either of two formats:
PostScript or ASCII. If the committee is unable to print a PostScript
submission, it will be returned and ASCII requested. Therefore,
PostScript submissions should arrive well before 15 August. If
electronic submission is absolutely impossible, submissions should be
sent via postal mail.
All submissions and other correspondence should be directed to the
Program Co-Chair:
David M. Balenson
Trusted Information Systems, Inc.
3060 Washington Road (Rt. 97)
Glenwood, Maryland 21738 USA
Phone: 301-854-6889
FAX: 301-854-5363
Email: balenson@tis.com
Each submission will be acknowledged through the medium by which it is
received. If acknowledgment is not received within seven days, please
contact the Program Co-Chair as indicated above. Authors and panelists
will be notified of acceptance by 17 October 1994. Instructions for
preparing camera-ready copy for the proceedings will be postal mailed
at that time. The camera-ready copy must be received by 15 November
1994.
-----
--
David M Balenson
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1994 20:50:22 GMT From: jdf@nitehawk.East.Sun.COM (Jim Fiori - Special Projects) To: comp.protocols.tcp-ip Subject: Re: long delay TCP
In article 7r5@ra.nrl.navy.mil, atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson) writes: >>> > Is there an implementation of a TCP for "long delay" connections like >>> > RFC1323 ? >>> > I need it for SunOS and Solaris. >>> >>> I believe that Solaris 2.x already implements RFC-1323. >> >>Nope. Someone at Sun told me it probably wouldn't make Solaris 2.4 either. >>Anyone at Sun care to comment? > > I talked with a developer inside Sun who said they had already done >it for Solaris; I wasn't blindly speculating. Now I wonder if it is a >"special" for Solaris rather than in the standard release. It would >help if Sun would comment on the record about this. > There is a consulting special called CONSULT-TCPLFN available for SunOS 4.X. See your local Sun rep for more information. As for Solaris 2.X, it's being worked on, but there has been no determination if/when/how it will ship. It will NOT be in 2.4. Jim
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 03 Jun 94 10:45:48 -0800 From: frank@calcom.socal.com (Frank Keeney) To: comp.protocols.tcp-ip Subject: Appletalk over tcp/ip how?
I can route tcp/ip over my localtalk net to allow MACs to communicate with
the rest of the ethernet. But how can I send Appletalk over a tcp/ip-only
WAN? What equipment/software would I need.
--
Frank Keeney | E-mail frank@calcom.socal.com
115 W. California Blvd., #411 | Fidonet 1:102/645
Pasadena, CA 91105-1509 USA | UUCP hatch!calcom!frank
| FAX +1 818 791-0578
| Voice Mail +1 818-791-0578 x402
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 1994 22:32:04 GMT From: mathews@ns9000.furman.edu (E. Owen Mathews) To: comp.protocols.tcp-ip Subject: comp.protocols.tcp-ip
I'm interested in comprehensive documentation of TCP/IP. I need to know details about the hardware level, the driver level, and the API level. Are there any good resources that you could recommend? I need to start from the very basic level, but I need some in-depth information as well. Any help would be appreciated. Owen Mathews (mathews()furman.edu)
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: 2 Jun 94 22:48:44 GMT From: cjw@nwu.edu (Christopher Wargaski) To: comp.protocols.tcp-ip Subject: Re: /etc/hosts /etc/named.data questions
In <d00n.770445200@crash.cts.com> d00n@crash.cts.com (Kevin Spousta) writes:
>I have 5 entries pointing to the same IP address and also mail exchange
>records in the /etc/named.data file to 'fake out' the machine called
>smtpgate into thinking it's many machines for addressing reasons. (Political
>reasons really) Is this OK? So far it works like a charm, but the keepers
>of the DNS say I can't do it like this.
And why not? It sure makes sense to me. In fact, Northwestern has a
machine that is doing multiple services and has multiple names (FQDN) all
with one IP address.
>Is it ok to have 1 IP for multiple hosts, when the actual host is *ONE*
>machine? I'm defending my position on the grounds that A) it works, and
>B) nothing seems to be affected by this 'trickery'. Can someone
>prove/disprove my thinking??
Sure, I will back you up. Consider this. You have one macine doing
end-all-be-all SMTP mail forwarding. If my local workstation does not know
where to send mail to joe@flop.slop.com, then I schwing it to a machine
that does mail relay service. Call it relay.acns.nwu.edu.
Say that machine does X.400 mail translation as well. Why not? It does
the end-all mail resolution anyway? Lets give it an address of
mhs.nwu.edu, because all X.400 mail would be sent there.
Well, this machine also happens to have a fax-modem on it, and is an
email-fax gateway. Mail a letter (with a certain username format) to
fax.acns.nwu.edu. It will fax it to a fax machine whose number you specify
in the user name.
Hmm, this machine also has the N.U. PH (campus wide email alias) database
on it. You can send mail to my alias cjw@nwu.edu and the machine nwu.edu
will send it to my real mailbox (cjw@moo.acns.nwu.edu).
Well, to resolve my PH alias to my real mailbox, I need to run a program
called phquery. Well a phquery asks a machine called ns.nwu.edu (this is
the way the code is written) to resolve the alias to actual email address.
So this poor Sparc 1 is doing all this work and has 5 names! (Just think,
this machine also used to the primary name server for the university!)
Well, in the near future, different machines will be doing different
services. It would be VERY difficult to do the big hardware switch-over
without the current configuration. I attribute this to the introspective
mind of a fellow colleague that did the work.
So, there is a reason why you should have different names for one physical
machine.
Hope it helped!
cjw
--
Christopher Wargaski cjw@nwu.edu Technical Services Supervisor
Northwestern University Network Operations Center 708-467-NNOC
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1994 08:43:01 -0500 From: gpalmer@blue.weeg.uiowa.edu (Gary Palmer) To: comp.sys.ibm.pc.rt,comp.protocols.tcp-ip Subject: Networking the old IBM RT-PC
Does anyone have experience in networking the IBM RT-PC (model 6150) to an ethernet network with TCP/IP? I have the IBM baseband ethernet card and have loaded the TCP/IP software. The hardware diagnostics seem to indicate that there is a good connection back to the network. But I cannot ping to/from the RT-PC. A few attempts to ping out result in an error message and the network software shutting down.
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Jun 1994 04:26:54 GMT From: fitz@wang.com (Tom Fitzgerald) To: comp.protocols.tcp-ip Subject: Re: /etc/hosts /etc/named.data questions
d00n@crash.cts.com (Kevin Spousta) writes: > I have 5 entries pointing to the same IP address and also mail exchange > records in the /etc/named.data file to 'fake out' the machine called > smtpgate into thinking it's many machines for addressing reasons. (Political > reasons really) Is this OK? So far it works like a charm, but the keepers > of the DNS say I can't do it like this. If you have both multiple A records, and multiple MX records, and all you care about is e-mail, then you've got a case of overkill, you don't need the A records at all, the MX's alone are enough. When you say "5 entries pointing to the same IP address" it's not clear if you mean 5 A records, or an A record and 4 CNAMEs; the other responses to your question seem to be unclear about this as well. CNAMEs are better than multiple A's, if you DON'T have e-mail going to all those names. If you do have mail going to all those names, and for some reason can't use MX's, then you do need to have multiple A's, and it does work (it's confusing to someone who's looking at the data, though). Note that you can't have both a CNAME record and any other record with the same name. (On the left-hand side of a record, I mean. It's fine to have multiple CNAMEs and MX's pointing to the same canonical name.) -- Tom Fitzgerald Wang Labs Lowell MA, USA 1-508-967-5278 fitz@wang.com
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Jun 1994 04:30:24 GMT From: fitz@wang.com (Tom Fitzgerald) To: comp.protocols.tcp-ip Subject: Re: Assign IP address to person or machine?
mcfowler@sol.rockwell.com (Mark C. Fowler) writes: > This has led to assigning IP addresses to people instead of > machines. My gut reaction is that this may cause problems, but I > can't quite come up with good arguments as to why. Laptops, shared systems, people borrowing other people's systems (to get at their printer/scanner/tape), people dialing in from home on PPP lines.... There's a real chance you'll get two systems on the net with the same address at the same time, and this will cause major problems. If you don't have these things now, you will soon. I vote for assigning IP addresses to machines, exclusively. -- Tom Fitzgerald Wang Labs Lowell MA, USA 1-508-967-5278 fitz@wang.com
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: Fri, 03 Jun 1994 14:23:20 -0500 From: patrickr@wr-hits.af.mil (Ron Patrick) To: comp.protocols.tcp-ip Subject: Internet Access in Saudi Arabia
Greetings,
I will be traveling to Saudi Arabia and what to be able to access the
internet. Does anyone know of a site that offers SLIP or Compuserve access
there? If this is not the proper place to post - please tell me where.
Thanks in advance for you help.
-Ron
P.S. Please email back to me directly as I do not read this newsgroup
often.
patrickr@wr-hits.af.mil
--
Ron Patrick Internet: patrickr@margie.robins.af.mil
WR-ALC,380 2nd St. STE 104
Robins AFB, GA 31098-1638 Voice: (912) 926-1313 FAX:(912) 926-2170
--------------------------------------------------------------------------
My thoughts are my own and not controlled by the government.
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1994 07:18:04 GMT From: xjbstah@solsta.ericsson.se (Stefan Ahser TX/DK, until 940701 resp etxjmik) To: comp.dcom.sys.cisco,comp.protocols.tcp-ip,comp.unix.admin,erinet.mailing-list.snmp,erinet.mailing-list.sun.managers,erinet.mailing-list.sun.nets,erinet.unix Subject: Help, mib on cisco-router in SunNet Manager.
Greetings
We are trying to get a cisco-mib to work through SunNet Manager (SnM), but we have some trouble.
We have installed a mib, we get the name of the agent (CISCO-MIB) to appear in the glyph-menu in SnM.
When we start the agent, first nothing happens for a while (about 1 min) and then we get the error:
Request CISCO-MIB.lifTable.0 has ended unexpectedly.
The standard snmp-agents (snmp, snmp-mibII) works, so we know that we have contact with the router,
but those agents dont give us the information we need.
Please help Stefan Ahser & Magnus Eriksson
Systeminfo
----------------------------------------
SPARCstation LX
----------------------------------------
OS-version: Solaris 2.3
----------------------------------------
SnM-version: SunNet Manager 2.2
----------------------------------------
MIB-version: cisco-mib 9.1
----------------------------------------
Routerdata (solsta-gw>sh version)
solsta-gw>sh version
GS Software (GS2-RX), Version 8.2(3)
Copyright (c) 1986-1991 by cisco Systems, Inc.
Compiled Tue 12-Feb-91 12:02 by mlb
System Bootstrap, Version 4.3(2)
solsta-gw uptime is 1 week, 3 days, 2 hours, 27 minutes
System restarted by reload
Running default software
CSC2 (68020) processor with 1024K bytes of memory.
X.25 software.
4 MCI controller.
8 Ethernet/IEEE 802.3 interface.
4 Serial network interface.
48K bytes of multibus memory.
32K bytes of non-volatile configuration memory.
Configuration register is 0x301
-------------------------------------------
\|||/
(. .)
+----------------------ooO-(_)-Ooo--------------------------+
Stefan Ahser Ericsson Telecom AB
xjbstah@solsta.ericsson.se Karlstad, Sweden
+-----------------------------------------------------------+
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1994 16:57:55 GMT From: leonard@telcom.arizona.edu (Aaron Leonard) To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
In article <RC5t2By.baldwinl@delphi.com>, baldwinl@delphi.com writes: |I'm currently troubleshooting a Telnet response time problem on a very heavily |u |utilized token ring (50%+). With a Sniffer, it seems to take nearly two |seconds for TCP to recover from a single dropped packet. After reading up |on TCP retransmission algorithms it almost seems like this is normal. Yup, that's just about normal--although the actual retransmission delay will be based upon TCP's estimated round-trip time. |If I understand it correctly TCP doesn't retransmit until after receiving |3 duplicate ACKs (packet out of order). Nope, TCP retransmits when it DOESN'T get ACKs (of course). |The configuration is an PC running OS/2 with IBM's IP stack communicating |with a Sun Sparc 1000. | |Also can anyone suggest further references on TCP retransmission algorithms? For a nice gory practical discussion, see chapter 21 in Stevens' _TCP/IP Illustrated_ (which you ought to buy in any case. Aaron Aaron Leonard (AL104), <Leonard@Arizona.EDU> University of Arizona Network Operations, Tucson AZ 85721 \ Don't lock yourself into open systems. /
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Jun 1994 18:16:57 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
>|If I understand it correctly TCP doesn't retransmit until after receiving >|3 duplicate ACKs (packet out of order). > >Nope, TCP retransmits when it DOESN'T get ACKs (of course). No. The reason for Jacobson's fast retransmit, fast recovery algorithm (retransmitting after receiving 3 duplicate ACKs) is to avoid having to wait for the retransmission timer to expire. You'll normally get the 3 duplicate ACKs before the timer expires, letting the sender keep the pipe filled before it empties. Rich Stevens
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1994 19:44:31 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: IP Loadsharing
In article <1994Jun1.210931.12927@acc.com> art@acc.com (Art Berggreen) writes:
>Last time I looked at BSD Unix, it was not capable of maintaining multiple
>equal cost routes in the kernel's routing table.
Hmm, I think SunOS and Ultrix just uses the old BSD routing table
implementation, and they have no problem with this. I've used the route(8)
command to install multiple routes to the same subnet, and they both get
used. I always assumed this is what the Refcnt field in the routing table
was for.
However, when a socket is connected, I believe it gets a reference to a
particular route, as an optimization. Thus, if there's only a single TCP
connection going to a destination with multiple routes, it won't take
advantage of the load sharing. But if you have multiple connections,
some will take one route while others will take the other.
Routed(8), on the other hand, will never install a new route to a
destination unless it has a strictly lower cost than one that it installed
previously. I don't know whether gated will do it, either.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1994 20:19:46 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: SO_REUSEADDR, etc.
In article <CqqAAu.5HC@xinet.com> jas@talking.COM (Jim Shankland) writes:
>So, my take on this is that SO_REUSEADDR is an unnecessary hack:
>there is no reason you shouldn't be able to bind a server socket to
>a port/address pair that is an endpoint of one or more connections
>in the TIME_WAIT state, as long as you don't allow re-creation
>of TCP connections ({lport, laddr, fport, faddr} quadruplets)
>that are in the TIME_WAIT state. BSD-based implementations
>are too restrictive when SO_REUSEADDR is not set, and (slightly)
>too permissive when SO_REUSEADDR *is* set. Or have I missed
>something?
Yes, you've got it correct. BSD-based implementations perform too simple a
test to see whether a local port is available -- it fails if any socket, in
any state, has the same local port.
>>Now UDP on a system that supports multicasting (e.g., Solaris 2.x) does
>>let you start multiple occurences of a server, all reading from the same
>>local port. But that's another story ...
>
>I don't understand why this should be coupled with multicast
>capability. That is, it seems perfectly reasonable to allow
>multiple servers to read from the same UDP port, even on a system
>that does *not* allow multicasting (and very desirable in some
>circumstances). Is there any reason other than happenstance
>that this is available only on multicast-capable systems?
Until multicast came along, there weren't many applications that needed
this capability. With multicast, you have the possibility that two users
on the same system will start up the same multicast-based application.
Since a multicast datagram can go to sockets on different systems, it makes
sense that it should also go to multiple sockets on the same system.
Prior to that, I suspect it just simplified the implementation, and no one
considered multiple, independent processes binding to the same port to be
sometime that was necessary. The most obvious, simplest way to implement
UDP is with a one-to-one localport->socket mapping.
Even unicast-only Unix systems support multiple processes listening on the
same port, but they have to be using the same socket. They can get the
socket either through inheritance (this is the most common way -- a process
binds a socket and then forks a bunch of children, and they all read from
it) or by passing it around through Unix domain sockets. Only when
multicast came along did the need for multiple
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: Fri, 3 Jun 1994 21:16:24 GMT From: jdunham@world.std.com (Jim Dunham) To: comp.protocols.tcp-ip Subject: Whose TCP/IP has an IP interface?
If your TCP/IP has enough hooks or the API for a protocol to talk directly through IP, please reply to this message. I'm interested in hearing about implementations for all versions of UNIX, Windows, OS/2, MacOS, NextStep, etc. I also need to know which implementations hide their IP and only present a UDP or TCP interface. Our product contains a protocol that runs directly over network-layer protocols, and needs a direct interface to IP. Thanks in advance, jim jdunham@world.std.com
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1994 22:46:39 GMT From: leonard@telcom.arizona.edu (Aaron Leonard) To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
In article <2snnej$em0@news.CCIT.Arizona.EDU>, leonard@telcom.arizona.edu (Aaron Leonard) writes: [...] || With a Sniffer, it seems to take nearly two ||seconds for TCP to recover from a single dropped packet. After reading up ||on TCP retransmission algorithms it almost seems like this is normal. | |Yup, that's just about normal--although the actual retransmission |delay will be based upon TCP's estimated round-trip time. | [...] |For a nice gory practical discussion, see chapter 21 in Stevens' |_TCP/IP Illustrated_ (which you ought to buy in any case. Rich Stevens corrected me (blush): |No. The reason for Jacobson's fast retransmit, fast recovery algorithm |(retransmitting after receiving 3 duplicate ACKs) is to avoid having to |wait for the retransmission timer to expire. You'll normally get the |3 duplicate ACKs before the timer expires, letting the sender keep the |pipe filled before it empties. | | Rich Stevens See, I told you: what Rich Stevens said! Aaron
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Sat, 4 Jun 1994 02:28:34 GMT From: vjs@calcite.rhyolite.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
In article <2snnej$em0@news.CCIT.Arizona.EDU> Leonard@Arizona.EDU writes: > >In article <RC5t2By.baldwinl@delphi.com>, baldwinl@delphi.com writes: > ... >|If I understand it correctly TCP doesn't retransmit until after receiving >|3 duplicate ACKs (packet out of order). > >Nope, TCP retransmits when it DOESN'T get ACKs (of course). What about Van Jacobson's fast retransmission algorithm which involves retransmissions in response to duplicate ACKs? Vernon Schryver vjs@rhyolite.com
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Sat, 4 Jun 1994 02:47:35 GMT From: kyma@netcom.com (Matt Young) To: comp.protocols.tcp-ip Subject: Voice
Fellow Netters: As part of my consulting business my clients are asking when can they send voice files over Internet. Hence, the title. Let me break down the question: Who is currently pushing for some delay management over routers which will allow voice support? What is the current state of the standards? Will a new ARP be required? Will SNMP play a major role in bandwidth management? The driving applications seems to be Whiteboard conferencing. Clients will want to manage conferences and sub-conferences within larger conferences. Current systems (Future labs) are struggling with having to maintain two different network environments, one for data and one for voice. Along with this, where are the ethernet vendors regarding a bandwidth management scheme for ethernet? IOf completed, how will an ethernet bandwidth management scheme be compatible with an enterprise wide TCP bandwidth management scheme? Are any voice vendors emerging with the goal of integrating voice across multiple platforms and network technologies? Thank You very much for your information. Matt Young KYMA
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: 4 Jun 1994 03:28:17 GMT From: mjr@tis.com (Marcus J Ranum) To: comp.protocols.tcp-ip Subject: Re: Voice
>As part of my consulting business my clients are asking >when can they send voice files over Internet. > >Hence, the title. Let me break down the question: > >Who is currently pushing for some delay management over >routers which will allow voice support? > >What is the current state of the standards? > >Will a new ARP be required? > >Will SNMP play a major role in bandwidth management? You forgot "why"? I'm as big a fan of neet tecknology as the next guy, but the best way to get guaranteed, uninterruptable bandwidth with relatively easy call setup and low hardware cost is - the telephone. I dread a day when we'll start getting 15Mb mail messages which take minutes to decode, and consist of someone saying, "uh, hi, uh, this is bob, uh, um, can you give me a call at around 2:00? uh, ok? thanks." And of course if I'm on the road, I have to login and download this crud in order to discover I've wasted my time? It's like when I worked for a certain Big Company and we had this one guy who blasted a message to a whole mailing list that was a huge 300kb Postscript file. Printed out, it was a 1 page memo with a cool page header graphic that said something about the company car plan. >As part of my consulting business my clients are asking >when can they send voice files over Internet. Sell them voice mail and tell 'em it's internet. They'll just love it. mjr.
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1994 08:31:36 +1200 From: qsmart@papaioea.manawatu.planet.co.nz (Quentin Smart) To: comp.protocols.tcp-ip Subject: Re: /etc/hosts /etc/named.data questions
In article <d00n.770445200@crash.cts.com>, Kevin Spousta <d00n@crash.cts.com> wrote: >I've been working on an SMTP gateway for Word Perfect Office and some of the >'trickery' I've done involves multiple hostnames for a single IP address in >the /etc/hosts file on our nameserver. Not being a total TCP/IP guru, I >have raised more than a few eyebrows with the way I've set up the nameservice >for this machine. ...... >Is it ok to have 1 IP for multiple hosts, when the actual host is *ONE* >machine? I'm defending my position on the grounds that A) it works, and >B) nothing seems to be affected by this 'trickery'. Can someone >prove/disprove my thinking?? > Using multiple MX records to point to one host is correct. And in fact is exactly how we recommend configuration of our SMTP WordPerfect Office gateway. - Quentin.
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: 3 Jun 1994 08:38:16 +1200 From: qsmart@papaioea.manawatu.planet.co.nz (Quentin Smart) To: comp.protocols.tcp-ip Subject: Re: /etc/hosts /etc/named.data questions
In article <sej.770467765@interaccess>, Stephen Johnson <sej@flowbee.interaccess.com> wrote: >d00n@crash.cts.com (Kevin Spousta) writes: > >>I've been working on an SMTP gateway for Word Perfect Office and some of the >>'trickery' I've done involves multiple hostnames for a single IP address in >>the /etc/hosts file on our nameserver. Not being a total TCP/IP guru, I >>have raised more than a few eyebrows with the way I've set up the nameservice >>for this machine. ...... > >I believe that multiple machine names (aka aliases) are not only OK but >supported under DNS using the CNAME record. However, I'm not an expert >on the arcane interactions between MX records and CNAME records and >aliasing a mail machine might cause problems of which I am unaware. > If you use a CNAME record you will most likely find that the mail turning up at your gateway has the addresses changed to what the CNAME record was pointing to. With an MX record the address will be preserved and you can then do your SMTP address to WPO host mapping.
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: 04 Jun 1994 05:16:50 GMT From: jtw@lcs.mit.edu (John Wroclawski) To: comp.protocols.tcp-ip Subject: Re: Voice
In article <kymaCquqFB.GJH@netcom.com> kyma@netcom.com (Matt Young) writes:
As part of my consulting business my clients are asking
when can they send voice files over Internet.
Are you talking about "live" voice or data files? Assuming you are
talking about live voice,
Who is currently pushing for some delay management over
routers which will allow voice support?
The IETF integrated services working group ("int-srv") is concerned
with developing overall architectural extensions to the internet
which will help to support these applications.
The IETF RSVP working group is concerned with developing and
standardizing RSVP, a protocol to support resource reservation in an
internet environment. This work takes particular account of multicast
and the requirements of heterogeneous systems.
The work mentioned above aims to add bandwidth management capabilities
to the IP protocol architecture. An alternative approach replaces IP
with a different internetwork protocol, STII, in situations where
bandwidth management is required. STII has been around for a while,
and has a number of implementations, although it is not widely
deployed.
The IETF AVT working group is concerned with transport protocols for
(pseudo) real-time data, encoding formats, and the like.
The IETF multimedia conferencing control wg ("MMUSIC") is looking at a
number of issues relating to conferencing applications and common
sesson-control standards.
In addition to these specific working groups, a number of activites
underway in the IETF, including advanced routing architectures (to
support choosing routes based on quality of service needs, and to
support wide-area multicast services), and the next-generation IP
design effort, will have an impact on supporting these applications.
A number of research and advanced development projects are
demonstrating the possibilities of this technology today. The MBONE is
a large (800+ network, 20+ countries) virtual network embedded in the
internet which supports multicast distribution of audio and video
programs, among other things. Some applications in wide use are the
"vat" audio tool, the "sd" session manager, and the "wb" shared
whiteboard, all from Lawrence Berkeley Labs; the "nv" video
conferencing tool from Xerox PARC, and the "ivs" video tool from
INRIA. (There are a number of other equally interesting projects
happening, and I certainly don't mean to single these out as the only
ones of merit...). A key point of all of these applications is their
focus on group communication as well as A-to-B communication. A lot of
effort is going into making sure the whole thing scales well.
What is the current state of the standards?
Young. The AVT folks have done a substantial amount of work, and are
nearing completion of some initial draft standards and profiles. These
will then enter the official IETF standards process, which allows (or
perhaps "requires") additional time for evaluation of the work. Most
of the other work is much newer, and while implementations will appear
quickly, actual IETF-approved standards will take longer.
It is important to understand what will be standardized and what won't
be. The intent is to standardize only those things which must be
agreed on globally, while leaving substantial flexibility in matters
of local concern, such as the scheduling algorithm used in a specific
router or network. This is because there is no one right answer for
all conditions, and because both applications and technology will
continue to improve over time.
Will a new ARP be required?
No.
Will SNMP play a major role in bandwidth management?
Seems unlikely, although it will play a role in allowing network
managers to control the link usage policies of their local routers.
This is a traditional network management role.
Along with this, where are the ethernet vendors regarding a
bandwidth management scheme for ethernet? If completed, how
will an ethernet bandwidth management scheme be compatible
with an enterprise wide TCP bandwidth management scheme?
First, experiments over several years have demonstrated that b/w
management is not always required at the local ethernet level. In
situations where it is, a couple of approaches are possible, depending
on whether you imagine that all nodes on the ethernet are cooperating
or not. An alternative to this is to put b/w management in a switching
hub, and use the hub-host connections as point-to-point links. This
alternative is simple to deploy and can give excellent performance.
The internet architectural work will use the bandwidth management
capabilities of lower-level nets where it exists. To handle a broader
spectrum of nets, one might assume that a b/w-managed internet path
will have a "reliability level" associated with it, as well as the
more traditional parameters. This matches well with the requirements
of perceptual applications. For example, you might put up with an
occasional crackle if you are just chatting with a group of friends,
but would demand excellent service if you were giving a remote piano
recital. In the first case, an uncontrolled ethernet would be OK. In
the second, it might not be. So the application should have a knob,
and the network should do path choice and bandwidth management to
provide whatever service the application needs.
regards,
-john
John Wroclawski
jtw@lcs.mit.edu
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 4 Jun 1994 06:31:10 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Assign IP address to person or machine?
In article <1994Jun2.182805.28009@nb.rockwell.com> mcfowler@sol.rockwell.com (Mark C. Fowler) writes:
> This has led to assigning IP addresses to people instead of
>machines. My gut reaction is that this may cause problems, but I
>can't quite come up with good arguments as to why.
What happens if a user logs in from two machines at the same time? They'll
both try to use the same IP address, won't they?
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: Sat, 4 Jun 1994 15:42:53 GMT From: dch2@netcom.com (D. Hobbs) To: comp.protocols.tcp-ip Subject: TCP/IP vs. LU 0 (tuning)
Hello All! I'd really like to start a discussion on tuning TCP/IP for various platforms (different Unix boxes, PCs/Macs, IBM/Tandem big boxes, etc.), but I don't know where these kinds of things are documented. For example, there are several people where I work that have pointed out various books, magazines, etc. on tuning LU 0 and LU 6.2 on SNA networks (VPACING, PACING, I-Frame size, RU Size, etc.), and this is all doc'd well in IBM literature (ok, you'll need about 10 different books weighing 100 lbs.). I have Comer's I and III (not II) volumes, but I don't see where he shows HOW/WHERE to modify settings. This seems reasonable since his books seem to avoid "platform-dependence." Are the Steven's books a good place? What about RFC's? I tend to doubt the Steven's books will do much good since they are more concerned with programming. And I'm afraid the RFC's might get too deep too quick, but I'm willing to look. What kind of recommendations do y'all have? Anyone care to just jump in and start this discussion? I once mentioned this to a friend of mine who manages a decent-sized Network. His recommendation was to leave TCP/IP alone since it could adversely affect overall network performance. I understand this point of view from him (being a network mgr), but I really want my TCP/IP to hum! I'm always being jabbed by my fellow SNA'ers about the speed of TCP/IP in our network (to IBM 3090). I can get access to make changes on MVS and Unix both. I also have customers asking these kinds of questions, and I'd really like to discuss this semi-intelligently with them. Thanks, D. -- David Hobbs dch2@netcom.com, 71175.166@compuserve.com All typos are my own. The spelling errors are someone else's.
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: Sat, 4 Jun 1994 16:58:56 GMT From: vjs@calcite.rhyolite.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: IP Loadsharing
In article <2so16vINNcpt@early-bird.think.com> barmar@think.com (Barry Margolin) writes: >In article <1994Jun1.210931.12927@acc.com> art@acc.com (Art Berggreen) writes: >>Last time I looked at BSD Unix, it was not capable of maintaining multiple >>equal cost routes in the kernel's routing table. > >Hmm, I think SunOS and Ultrix just uses the old BSD routing table >implementation, and they have no problem with this. I've used the route(8) >command to install multiple routes to the same subnet, and they both get >used. I always assumed this is what the Refcnt field in the routing table >was for. > >However, when a socket is connected, I believe it gets a reference to a >particular route, as an optimization. Thus, if there's only a single TCP >connection going to a destination with multiple routes, it won't take >advantage of the load sharing. But if you have multiple connections, >some will take one route while others will take the other. > ... The old style (4.3BSD) code I think I know about does cache a pointer to the route with each TCP connection, and so different TCP connections can use different routes. However, each time the system looks for a route, it simply looks for the first one. Unless the routing table is change (either manually or by a daemon), all TCP connections will use the same route. There is no load sharing. People regularly suggests patches that rotate entries in the routing table so that such load sharing would happen. That routing table look up can happen on every UDP transmission, which is why under some circumstances, UDP can be slower than TCP. Vernon Schryver vjs@rhyolite.com
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: Sat, 4 Jun 1994 17:22:10 GMT From: gnn@netcom.com (George Neville-Neil) To: comp.protocols.tcp-ip Subject: TCP-IP FAQ for June 1994
Hi Folks,
OK here is the latest FAQ, complete with corrections and some
additions. Remember, this is also available for anonymous ftp from
ftp.netcom.com:~ftp/pub/gnn/tcp-ip.faq
Enjoy,
George
Internet Protocol Frequently Asked Questions
Maintained by: George V. Neville-Neil (gnn@netcom.com)
Contributions from:
Ran Atkinson
Stephane Bortzmeyer
Phill Conrad
Jon Kay
Barry Margolin
Jim Muchow
W. Richard Stevens
Version 1.2
Last Update: June 4, 1994
************************************************************************
The following is a list of Frequently Asked Questions, and
their answers, for people interested in the Internet Protocols,
including TCP, UDP, ICMP and others. Please send all additions,
corrections, complaints and kudos to the above address. This FAQ will
be posted on or about the first of every month.
************************************************************************
Table of Contents:
Glossary
1) Are there any good books on IP?
2) Where can I find example source code for TCP/UDP/IP?
3) Are there any public domain programs to check the performance of an
IP link?
4) Where do I find RFCs?
5) How can I detect that the other end of a TCP connection has
crashed? Can I use "keepalives" for this?
6) Can the keepalive timeouts be configured?
7) Can I set up a gateway to the Internet that translates IP
addresses, so that I don't have to change all our internal addresses
to an official network?
Glossary:
I felt this should be first given the plethora of acronyms used in the
rest of this FAQ.
IP: Internet Protocol. The lowest layer protocol defined in TCP/IP.
This is the base layer on which all other protocols mentioned herein
are built. IP is often referred to as TCP/IP as well.
UDP: User Datagram Protocol. This is a connectionless protocol built
on top of IP. It does not provide any guarantees on the ordering or
delivery of messages. This protocol is layered on top of IP.
TCP: Transmission Control Protocol. TCP is a connection oriented
protocol that guarantees that messages are delivered in the order in
which they were sent and that all messages are delivered. If a TCP
connection cannot deliver a message it closes the connection and
informs the entity that created it. This protocol is layered on top
of IP.
ICMP: Internet Control Message Protocol. ICMP is used for
diagnostics in the network. The Unix program, ping, uses ICMP
messages to detect the status of other hosts in the net. ICMP
messages can either be queries (in the case of ping) or error reports,
such as when a network is unreachable.
RFC: Request For Comment. RFCs are documents that define the
protocols used in the IP Internet. Some are only suggestions, some
are even jokes, and others are published standards. Several sites in
the Internet store RFCs and make them available for anonymous ftp.
SLIP: Serial Line IP. An implementation of IP for use over a serial
link (modem). CSLIP is an optimized (compressed) version of SLIP that
gives better throughput.
Bandwidth: The amount of data that can be pushed through a link in
unit time. Usually measured in bits or bytes per second.
Latency: The amount of time that a message spends in a network going
from point A to point B.
Jitter: The effect seen when latency is not a constant. That is, if
messages experience a different latencies between two points in a
network.
RPC: Remote Procedure Call. RPC is a method of making network access
to resource transparent to the application programmer by supplying a
"stub" routine that is called in the same way as a regular procedure
call. The stub actually performs the call across the network to
another computer.
Marshalling: The process of taking arbitrary data (characters,
integers, structures) and packing them up for transmission across a
network.
MBONE: A virtual network that is a Multicast backBONE. It is still a
research prototype, but it extends through most of the core of the
Internet (including North America, Europe, and Australia). It uses IP
Multicasting which is defined in RFC-1112. An MBONE FAQ is available
via anonymous ftp from: ftp.isi.edu" There are frequent broadcasts of
multimedia programs (audio and low bandwidth video) over the MBONE.
1) Are there any good books on IP?
A) Yes. Please see the following:
Internetworking with TCP/IP Volume I
(Principles, Protocols, and Architecture)
Douglas E. Comer
Prentice Hall 1991
This volume covers all of the protocols, including IP, UDP, TCP, and
the gateway protocols. It also includes discussions of higher level
protocols such as FTP, TELNET, and NFS.
Internetworking with TCP/IP Volume II
(Design, Implementation, and Internals)
Douglas E. Comer / David L. Stevens
Prentice Hall 1991
Discusses the implementation of the protocols and gives numerous code
examples.
Internetworking with TCP/IP Volume III (BSD Socket Version)
(Client - Server Programming and Applications)
Douglas E. Comer / David L. Stevens
Prentice Hall 1993
This book discusses programming applications that use the internet
protocols. It includes examples of telnet, ftp clients and servers.
Discusses RPC and XDR at length.
TCP/IP Illustrated, Volume 1: The Protocols,
W. Richard Stevens
(c) Addison-Wesley, 1994
An excellent introduction to the entire TCP/IP protocol suite,
covering all the major protocols, plus several important applications.
Unix Network Programming
W. Richard Stevens
Prentice Hall 1990
An excellent introduction to network programming under Unix.
The Design and Implementation of the 4.3 BSD Operating System
Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, John S.
Quarterman
Addison-Wesley 1989
Though this book is a reference for the entire operating system, the
eleventh and twelfth chapters completely explain how the networking
protocols are implemented in the kernel.
2) Where can I find example source code for TCP/UDP/IP?
A) Code from the Internetworking with TCP/IP Volume III is available
for anonymous ftp from:
arthur.cs.purdue.edu:/pub/dls
Code used in the Net-2 version of Berkeley Unix is available for
anonymous ftp from:
ftp.uu.net:systems/unix/bsd-sources/sys/netinet
and
gatekeeper.dec.com:/pub/BSD/net2/sys/netinet
Code from Richard Steven's book is available on:
ftp.uu.net:/published/books/stevens.*
3) Are there any public domain programs to check the performance of
an IP link?
A)
TTCP: Available for anonymous ftp from....
Host gatekeeper.dec.com
Location: /.0/BSD/NetBSD/NetBSD-current/othersrc
DIRECTORY dr-xr-xr-x 512 Apr 8 09:57 ttcp
Location: /.0/BSD/NetBSD/NetBSD-current/othersrc/ttcp
FILE -r--r--r-- 3885 Nov 7 03:35 ttcp.1
FILE -r--r--r-- 19225 Nov 7 03:35 ttcp.c
Host world.std.com
Location: /src/wuarchive/graphics/graphics/mirrors/sgi.com/sgi/src/ttcp
FILE -r--r--r-- 3885 Oct 4 1991 ttcp.1
FILE -r--r--r-- 19170 May 17 1993 ttcp.c
FILE -r--r--r-- 13033 Sep 5 1989 ttcp.c-brl
On ftp.sgi.com are netperf (from Rick Jones at HP) and nettest
(from Dave Borman at Cray). ttcp is also availabel at ftp.sgi.com.
There is suite of Bandwidth Measuring programs from gnn@netcom.com.
Available for anonymous ftp from ftp.netcom.com in
~ftp/gnn/bwmeas-0.3.tar.Z These are several programs that meausre
bandwidth and jitter over several kinds of IPC links, including TCP
and UDP.
4) Where do I find RFCs?
A) RFCs are available for anonymous ftp from the following servers.
You should pick the one geographically closest to you.
North America
ftp.internic.net (canonical set)
FTP.NISC.SRI.COM
and nic.cerf.net
Austrailia and Pacific Rim
munnari.oz.au
Denmark
ftp.denet.dk
Germany
walhalla.informatik.uni-dortmund.de
Finland
funet.fi
Netherlands
mcsun.eu.net
Norway
ugle.unit.no
Sweden
sunic.sunet.se and chalmers.se
Using Web, WAIS, and gopher:
Web:
http://web.nexor.co.uk/rfc-index/rfc-index-search-form.html
WAIS access by keyword:
wais://wais.cnam.fr/RFC
Excellent presentation with a full-text search too:
http://www.cis.ohio-state.edu/hypertext/information/rfc.html
With Gopher:
gopher://r2d2.jvnc.net/11/Internet%20Resources/RFC
gopher://muspin.gsfc.nasa.gov:4320/1g2go4%20ds.internic.net%2070%201%201/.ds/
.internetdocs
5) How can I detect that the other end of a TCP connection has crashed?
Can I use "keepalives" for this?
A) Detecting crashed systems over TCP/IP is difficult. TCP doesn't require
any transmission over a connection if the application isn't sending
anything, and many of the media over which TCP/IP is used (e.g. ethernet)
don't provide a reliable way to determine whether a particular host is up.
If a server doesn't hear from a client, it could be because it has nothing
to say, some network between the server and client may be down, the server
or client's network interface may be disconnected, or the client may have
crashed. Network failures are often temporary (a thin ethernet will appear
down while someone is adding a link to the daisy chain, and it often takes
a few minutes for new routes to stabilize when a router goes down), and TCP
connections shouldn't be dropped as a result.
Keepalives are a feature of the sockets API that requests that an empty
packet be sent periodically over an idle connection; this should evoke an
acknowledgement from the remote system if it is still up, a reset if it has
rebooted, and a timeout if it is down. These are not normally sent until
the connection has been idle for a few hours. The purpose isn't to detect
a crash immediately, but to keep unnecessary resources from being allocated
forever.
If more rapid detection of remote failures is required, this should be
implemented in the application protocol. There is no standard mechanism
for this, but an example is requiring clients to send a "no-op" message
every minute or two. An example protocol that uses this is X Display
Manager Control Protocol (XDMCP), part of the X Window System, Version 11;
the XDM server managing a session periodically sends a Sync command to the
display server, which should evoke an application-level response, and
resets the session if it doesn't get a response (this is actually an
example of a poor implementation, as a timeout can occur if another client
"grabs" the server for too long).
6) Can the keepalive timeouts be configured?
A) I know they can on many systems, but I don't know the details.
7) Can I set up a gateway to the Internet that translates IP addresses, so
that I don't have to change all our internal addresses to an official
network?
A) There's no general solution to this. Many protocols include IP
addresses in the application-level data (FTP's "PORT" command is the most
notable), so it isn't simply a matter of translating addresses in the IP
header. Also, if the network number(s) you're using match those assigned
to another organization, your gateway won't be able to communicate with
that organization (RFC 1597 proposes network numbers that are reserved for
private use, to avoid such conflicts, but if you're already using a
different network number this won't help you).
However, if you're willing to live with limited access to the Internet from
internal hosts, the "proxy" servers developed for firewalls can be used as
a substitute for an address-translating gateway. See the firewall FAQ.
--
gnn@netcom.com
Gentlemen, I will not have you fighting in the War Room.
--- The President in Dr. Strangelove
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 1994 01:02:23 -0400 From: adiwan@bbn.com (Arif Diwan) To: comp.unix.internals,comp.unix.wizards,comp.protocols.tcp-ip Subject: Re: Way for faster IPC than TCP/IP ?
In article <2rtmdiINNmvs@duncan.cs.utk.edu>,
hzhou@cs.utk.edu (Honbo Zhou) writes:
>I would like to know if there is a way to do faster IPC between processes
>on different machines than TCP/IP. I am aware of RAW socket. Unfortunately,
>it need to have root access.
Why would you want to do that? You will probably not gain much over UDP
let alone RAW IP. I can get close to wire speed no loss thruput over
Ethernet or FDDI using the TCP/IP stack (UDP). The limiting factor is
your hardware (interface card + bus etc) and your OS.
Here are some figures [pps = packets/sec]:
Ethernet (Theoretical wire speed: 10MB/s):
8400 pps 128 byte packets -> 8.2 MB/s
1200 pps 1024 byte packets -> 9.375 MB/s
and this is going across an ethernet thru a router, across a FDDI ring,
thru another router and back out on another ethernet, traversing TCP/IP
stacks all along -without- dropping a single packet and running
continuously while other activity is going on at the routers and the
end systems (OSPF etc etc)!
FDDI (Theoretical wire speed: 100MB/s):
9500 pps 1024 byte packets -> 74.2 MB/s
going over three FDDI rings, two routers and two end stations. Here the
results do not appear to be that great but the problem is in the FDDI
driver which needs tuning. The scenario is the same as above
otherwise.
If I stay on just one ring or ethernet segment then I can pump very
close to wire speed - over 95%.
--
-- Arif Diwan (adiwan@bbn.com)
617.873.6274
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: Sun, 5 Jun 1994 02:15:53 From: tnert@bisque.cc.utexas.edu (Trent Stevens) To: comp.protocols.tcp-ip Subject: Re: Voice
In article <2srjq7$f7t@gaia.internex.net> Blaine Kubesh <blaine@sonicsys.com> writes: >You can send voice over the internet right now. There is a Macintosh App >called Maven that will do the trick. It is an internet speech program >that allows two people to talk over the Internet using your microphone >sound input. Query archie for the exact whereabouts. If you cannot find >it let me know and I will send it to you. You can do the same with Windows, using Internet Voice Chat by Richard Ahrens. The filename is IVC10.ZIP. >You will need a Macintosh with MacTCP and Sound Manager 3.0 to use it. You need a PC running Windows, a sound card, a microphone, and a network connection in conjunction with a Winsock to run IVC. I haven't gotten it to work correctly yet, but that may be because I'm using SLIP! Trent Stevens tnert@bisque.cc.utexas.edu
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: Sat, 4 Jun 1994 23:45:36 GMT From: root@sizone.pci.on.ca (the mouth is where the lies come from) To: comp.protocols.tcp-ip Subject: 'host' problems
I have 'host' for linux setup... well, I got the binaries, which I assume
were compiled correctly since they were on sunsite.
For some reason, I cant get IP#s for hosts outside the university! (my
slip is provided from the u.) - it seems as if only stuff in THEIR
/etc/hosts (I moved mine to a different name to see if it was affecting
things) is reported. For eg, even using uunet.ca as domain server
(usually its spadina.csri. toronto.edu which is what alot of systems at
UfT use) doesnt work - only for local university sites! What gives?
Are they stuck with giving info from their /etc/hosts only and when I use
another server it doesnt route my request out of the domain i'm SLIPed to?
(I dont know much about this stuff...)
I had the domain in my /etc/resolv.conf set to our local network domain
name and the nameserver set to my slip provider's IP# - nameservice
works fine with them as I said, but I couldnt get host to even match
ANYTHING until I set the resolv.conf domain to match my real internet
domain (as opposed to the local domain, since only one machine as a net
IP#). Now local hosts at the university are reported, but anything
outside that reports "host not found".
I've read the man page for 'host', and I grepped for "resolv.conf" here ('host'
comes up with too many matches!) but found nothing, so I am posting. Sorry
if this is duplicating info elsewhere.
/kc
--
Ken P. Chasse -- Sysadmin, Sonic Interzone - Marion Boyd & the OPP must
Public Access email/Usenet -- 416-968-7292 acknowledge that carrying netnews
spooge@sizone.pci.on.ca -- Toronto, CANADA does NOT a publisher make!
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 1994 04:20:23 GMT From: Blaine Kubesh <blaine@sonicsys.com> To: comp.protocols.tcp-ip Subject: Re: Voice
In article <kymaCquqFB.GJH@netcom.com> Matt Young, kyma@netcom.com writes: > As part of my consulting business my clients are asking > when can they send voice files over Internet. You can send voice over the internet right now. There is a Macintosh App called Maven that will do the trick. It is an internet speech program that allows two people to talk over the Internet using your microphone sound input. Query archie for the exact whereabouts. If you cannot find it let me know and I will send it to you. You will need a Macintosh with MacTCP and Sound Manager 3.0 to use it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Blaine Kubesh Internet: blaine@sonicsys.com Sonic Systems, Inc. Call Sign: ke6gsx =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: Sun, 5 Jun 94 17:26:30 -0500 From: baldwinl@delphi.com To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
W. Richard Stevens <rstevens@noao.edu> writes: >>|If I understand it correctly TCP doesn't retransmit until after receiving >>|3 duplicate ACKs (packet out of order). >> >>Nope, TCP retransmits when it DOESN'T get ACKs (of course). > >No. The reason for Jacobson's fast retransmit, fast recovery algorithm >(retransmitting after receiving 3 duplicate ACKs) is to avoid having to >wait for the retransmission timer to expire. You'll normally get the >3 duplicate ACKs before the timer expires, letting the sender keep the >pipe filled before it empties. First let me say that I do own "TCP/IP Illustrated" and I think its the best packet level book on TCP/IP on the market. I must say however, that TCP retransmissions was one of the very few places where you lost me. Back to the issue. My understanding of TCP retransmissions has now been enhanced as follows: 1) Sender measures round trip response time More? 2) Sender setsretransmit timeout (RTO) to 2x RTT (or more?) 3) RTO varies depending on future RTT 4) Sender sends packet and sets retransmission timer 5) Sender continues to send packets as long as there is available window and RTO seconds have not expired, unless: 6) However, if: a) RTO seconds expire before receiving ACK -or- b) Three (may vary?) duplicate ACKs received from receiver then: INITIATE RETRANSMIT Is this more accurate?
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 1994 13:19:01 GMT From: etxkrjg@solsta.ericsson.se (Kristian Jorg TX/DK) To: comp.protocols.tcp-ip,comp.protocols.ppp Subject: Re: cslip-2.7 for sunos4.1.3
References: <ZHAO.94Jun1161354@sparta.crl.nmsu.edu> zhao@crl.nmsu.edu (Z. Zhao) writes: >Hello, >I am trying to implement cslip-2.7 on a sparc10/sunos4.1.3. >I am confused about setting config file options for SLMTU. >Should I set > options SLMTU >or > options SLMTU=<N> >or > options SLMTU=<260> >in the SYS_NAME file? >'# config SYS_NAME' would say "options SLMTU=<N>" is a syntax error. >SLMTU=<260> makes sense? try: options SLMTU=260 After you have run config and started make you will see the -DSLMTU=260 somewhere in the compilation commands that make creates. If not, something is still wrong... /Kristian >ZiZi -- _______________________________________________________ Kristian Jörg, Design Tools Development and Support Ericsson Telecom AB, Karlstad, Sweden E-mail: etxkrjg@solsta.ericsson.se, Tel: +46 54 193149
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 1994 13:36:09 GMT From: rodney@sabletech.com (Rodney Thayer) To: comp.protocols.tcp-ip Subject: DHCP Server
Can anybody recommend a DHCP server - on any platform? Is there an update to the bsd bootp server to add dhcp support?
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: Sun, 5 Jun 1994 15:27:28 GMT From: kyma@netcom.com (Matt Young) To: comp.protocols.tcp-ip Subject: Re: Voice
John Wroclawski (jtw@lcs.mit.edu) wrote:
Thanks John for stepping up to the plate on this issue.
Now to help us all out, can I have you expand on some
of the issues you raised. Users need to have a flavor of
some of the issues so they can make intelligent choices
from the various proposals which will result.
: Are you talking about "live" voice or data files? Assuming you are
: talking about live voice,
Yes, live interactive.
: Who is currently pushing for some delay management over
: routers which will allow voice support?
: The IETF integrated services working group ("int-srv") is concerned
: with developing overall architectural extensions to the internet
: which will help to support these applications.
: The IETF RSVP working group is concerned with developing and
: standardizing RSVP, a protocol to support resource reservation in an
: internet environment. This work takes particular account of multicast
: and the requirements of heterogeneous systems.
How does RSVP work, say compared to an ARP. I use ARP as an
example since it is an approximation to call set up. Is RVSP like
a call set up? Does one issue an RSVP to modify the delay and
throughput characteristics of a particular connection?
What is used to identify a connection that has resource reservation?
It must be identified in intermediate nodes, is their a resource
ID associated with a particular Source-Destination IP pair?
: The work mentioned above aims to add bandwidth management capabilities
: to the IP protocol architecture. An alternative approach replaces IP
: with a different internetwork protocol, STII, in situations where
: bandwidth management is required. STII has been around for a while,
: and has a number of implementations, although it is not widely
: deployed.
Explain a little more about STII. Is it lighter weight IP?
What does it claim to have that IP doesn't have?
: The IETF multimedia conferencing control wg ("MMUSIC") is looking at a
: number of issues relating to conferencing applications and common
: sesson-control standards.
: In addition to these specific working groups, a number of activites
: underway in the IETF, including advanced routing architectures (to
: support choosing routes based on quality of service needs, and to
: support wide-area multicast services), and the next-generation IP
: design effort, will have an impact on supporting these applications.
Explain the issues regarding next generation IP? Is easier IP
switching an issues? How about a VCI style address option?
: A number of research and advanced development projects are
: demonstrating the possibilities of this technology today. The MBONE is
: a large (800+ network, 20+ countries) virtual network embedded in the
: internet which supports multicast distribution of audio and video
: programs, among other things.
Great, what form of the various directions mentioned above are
they using. Is this being demoed with standard IP using the
RSVP mechanism?
Some applications in wide use are the
: "vat" audio tool, the "sd" session manager, and the "wb" shared
: whiteboard, all from Lawrence Berkeley Labs; the "nv" video
: conferencing tool from Xerox PARC, and the "ivs" video tool from
: INRIA. (There are a number of other equally interesting projects
: happening, and I certainly don't mean to single these out as the only
: ones of merit...). A key point of all of these applications is their
: focus on group communication as well as A-to-B communication. A lot of
: effort is going into making sure the whole thing scales well.
: It is important to understand what will be standardized and what won't
: be. The intent is to standardize only those things which must be
: agreed on globally, while leaving substantial flexibility in matters
: of local concern, such as the scheduling algorithm used in a specific
: router or network. This is because there is no one right answer for
: all conditions, and because both applications and technology will
: continue to improve over time.
: Along with this, where are the ethernet vendors regarding a
: bandwidth management scheme for ethernet? If completed, how
: will an ethernet bandwidth management scheme be compatible
: with an enterprise wide TCP bandwidth management scheme?
: First, experiments over several years have demonstrated that b/w
: management is not always required at the local ethernet level.
You mean if someone makes a long file transfer, then my phone
call isn't bashed? Don't we have to at least limit packet sizes?
Is a corporation going to place critical white board activities
in an environment where long file transfers shake thing up?
: In
: situations where it is, a couple of approaches are possible, depending
: on whether you imagine that all nodes on the ethernet are cooperating
: or not. An alternative to this is to put b/w management in a switching
: hub, and use the hub-host connections as point-to-point links. This
: alternative is simple to deploy and can give excellent performance.
Good introduction to the next question. ISO Ethernet is one solution
gaining some adherents. Is this the solution from National
Semiconductor with Apple support?
Does anyone know how Intel is going to meet resource reservation
for their Indeo conferencing over ethernet?
Ethernet management which assume cooperating nodes yield one or two
approaches. A simple one says that each node simply observes a
period time period in which only reserved activity takes place. Who
is working on solutions like this?
: The internet architectural work will use the bandwidth management
: capabilities of lower-level nets where it exists.
And I assume that SNMP management will cross all layers, allowing
some semblence of uniform monitoring, if not control.
To handle a broader
: spectrum of nets, one might assume that a b/w-managed internet path
: will have a "reliability level" associated with it, as well as the
: more traditional parameters. This matches well with the requirements
: of perceptual applications. For example, you might put up with an
: occasional crackle if you are just chatting with a group of friends,
: but would demand excellent service if you were giving a remote piano
: recital. In the first case, an uncontrolled ethernet would be OK. In
: the second, it might not be. So the application should have a knob,
: and the network should do path choice and bandwidth management to
: provide whatever service the application needs.
: regards,
: -john
: John Wroclawski
: jtw@lcs.mit.edu
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 1994 16:40:39 GMT From: km@mathcs.emory.edu (Ken Mandelberg) To: comp.protocols.tcp-ip Subject: TCP over ATM reading list?
Does anyone have a bibliography for TCP over ATM?
---
Ken Mandelberg | km@mathcs.emory.edu PREFERRED
Emory University | {rutgers,gatech}!emory!km UUCP
Dept of Math and CS | km@emory.bitnet NON-DOMAIN BITNET
Atlanta, GA 30322 | Phone: Voice (404) 727-7963, FAX 727-5611
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 01:42:59 -0500 From: greg@gagme.wwa.com (Gregory Gulik) To: comp.protocols.tcp-ip Subject: bootp and SLIP?
A customer inquired about using bootp to receive his nodes parameters (hostname, netmask, etc..) when dialing in on a SLIP connection. Is this possible? I thought that bootp needed a hardware address to work. Can someone clear this up or show how it can be done? I've tried several configurations, but nothing works. I know bootp works since we use it with our Xterminals. -- Gregory Gulik greg@wwa.com http://gagme.wwa.com/~greg Computing Engineers, Inc. Home of WorldWide Access (SM) Data: +1 312 282 8605 +1 708 367 1871 Voice: +1 708 367 1870 Info: info@wwa.com Support: support@wwa.com
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 94 23:46:22 From: billw@glare.cisco.com (William ) To: comp.protocols.tcp-ip,comp.security.unix Subject: Re: Is IP source routing a bad idea?
A correct and bug-free implementation of IP source routing allows any host on the internet to masquerade as any IP address that it would like to, thus breaking any access control based on the source IP address (eg, most of the unix r-utilities.) Exactly how to do this is left as an excercise to the reader, but the fundamental problem is that the source route allows the packet to travel "through" possibly suspect IP entities that have not had the slightest amount of authentication as "trustworthy" routers applied to them. BillW cisco
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 94 00:47:36 From: billw@glare.cisco.com (William ) To: comp.protocols.tcp-ip Subject: Re: bootp and SLIP?
A customer inquired about using bootp to receive his nodes
parameters (hostname, netmask, etc..) when dialing in on
a SLIP connection.
Is this possible?
I thought that bootp needed a hardware address to work.
Some SLIP servers can support this by using the particular async port to
"imply" a hardware address. (eg, you only really need a HW address to
differeniate between hosts on a broadcast network like ethernet.) This
does pretty much require that the bootp server be implemented on the slip
server itself, rather than have the slip server forward the bootp request
to some other server on the net.
BillW
cisco
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: 5 Jun 1994 17:16:50 +0200 From: jor@krynn.solace.mh.se (Joakim Rastberg) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,vmsnet.networks.tcp-ip.misc Subject: Put/Get files on PC (in a TSR, under DOS, while running another program
Goddag Does anyone have a Terminate-and-Stay-Resident (TSR) version of ftpd for any standard TCPIP-stack under DOS? I need to put/get/delete files on a PC that is simultaneously running a data acquisition program. No, I cannot use Windows in this case, the application is Rational DOS4GW 32bit extended (methinx Windows don't allow that:-) I have found some ftpd's under DOS (such as the one in PCTCP) but they don't allow another application to run at the same time. TCPIP stack on NDIS (using ISDN but thats beside the point). It is ok for the data acquisition programs to supended during a ftp session, I dont play to put/get any files during critical measures. SHARE is ok too... If anyone answers I will summarize. Joakim Rastberg ------- Joakim (jor@solace.mh.se) Rastberg, Solace Computer Society, Sundsvall, Sweden Important note: This posting was a shareware. If you read it more than once, send me all your money. Then go and see a psychologist. Or kill me.
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: Sun, 5 Jun 1994 21:54:07 GMT From: davido@flagstaff.Princeton.EDU (David Lawrence Oppenheimer) To: comp.unix.admin,comp.unix.misc,comp.unix.questions,comp.sys.sun.admin,comp.sys.sun.apps,comp.sys.sun.misc,comp.protocols.tcp-ip Subject: Need cslip help!
I am having a very difficult time trying to get cslip to work on my Sun SS5. (I am using the version currently on the math.berkeley.edu FTP site.) Pertinent information: I am using a Sun SS5 with SunOS 4.1.3_U1. I am using a Hayes modem but am having no trouble communicating with the modem (i.e. regular tip dialout works). I do not have Ethernet connected to my system, just the modem through Serial Port A. I have created /dev/cua0 as specified in the cslip instructions. I have installed the cslip loadable kernel module for sun4m. I have modified the cslip login script to suit the SLIP terminal server I dial into. My problem: I run on_all_times as root (after modifying the /etc/remote, /etc/phones, slip.hosts, slip.login, and slip.logout files appropriately for my site) and get "login failed: exit status 2 from /etc/slip.login" Then I decided to try the commands by hand. First I did ifconfig sl0 my_ip_address terminal_server_ip_address netmask correct_netmask but I get ifconfig: ioctl (SIOCSIFADDR): Invalid argument I have no idea what the invalid argument is here--this fits the argument prototype given in the man page! Sometimes (and I don't know how) the ifconfig gets configured right, i.e. when I do an ifconfig -a I get the correct information. I am always able to get the route -n add default default_ip_address to work. On the rare occassions when I am able to get the ifconfig to register, when I run sliplogin davido (davido is the name in my slip.hosts file) nothing happens. I must be missing something here--I am not sure what else I am supposed to do. When I try ping, the machine goes for the Ethernet port (I have no ethernet connection) so I get a bunch of le0 errors on the console. When I try "ifconfig le0 down" the whole machine crashes. :-( I assume that the "exit code 2" from /etc/slip.login is a result of ifconfig failing with the SIOCSIFADDR error. But perhaps someone could explain why I get the SIOCSIFADDR error? [The man page said this means I gave a bad interface address.] I have my machine listed in /etc/hosts as well as in the NIS database (I am running my machine as an NIS server) but this really shouldn't matter since I am using IP addresses and not hostnames. Any help would be appreciated! Please respond by email; I will summarize the answers in the newsgroups to which I am posting this message. Thanks, David Oppenheimer davido@phoenix.Princeton.EDU
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: Sun, 5 Jun 1994 22:27:53 GMT From: rturner@qms.com (Randy Turner) To: comp.protocols.tcp-ip Subject: BSD-style socketlib for MacTCP
Does anyone know if there is a BSD-style socket library interface for MacTCP? or, if not, is Apple working on one? Thanks! Randy --- /* Rt */
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: Mon, 6 Jun 1994 02:19:31 GMT From: ashok@biochemistry.cwru.edu (Ashok Aiyar) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,vmsnet.networks.tcp-ip.misc Subject: Re: Put/Get files on PC (in a TSR, under DOS, while running another program
In article <jor.770829337@krynn> jor@krynn.solace.mh.se (Joakim Rastberg) writes: >Goddag >Does anyone have a Terminate-and-Stay-Resident (TSR) version of ftpd >for any standard TCPIP-stack under DOS? >I need to put/get/delete files on a PC that is simultaneously running >a data acquisition program. I know of a TSR version of KA9Q that has an FTP server, and supports packet drivers. This was compiled by Jonathan Bloom sometime around 1990-'91. It loads as a large (130KB) TSR, and works quite well. You can pick it using the following URL. file://shasta.scl.cwru.edu/dos/tcpip/ka9q/tsrnet.arc Later, Ashok -- Ashok Aiyar Mail: ashok@biochemistry.cwru.edu Department of Biochemistry Tel: (216) 368-3300 CWRU School of Medicine, Cleveland, Ohio Fax: (216) 368-4544 MIME Enclosures OK
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 10:51:28 -0500 From: dpm@bga.com (David P. Maynard) To: comp.protocols.tcp-ip Subject: Re: bootp and SLIP?
John Hascall <john@iastate.edu> wrote: >William <billw@glare.cisco.com> wrote: >} A customer inquired about using bootp to receive his nodes >} parameters (hostname, netmask, etc..) when dialing in on >} a SLIP connection. >} >} Is this possible? >} I thought that bootp needed a hardware address to work. >} >}Some SLIP servers can support this by using the particular async port to >}"imply" a hardware address. (eg, you only really need a HW address to >}differeniate between hosts on a broadcast network like ethernet.) This >}does pretty much require that the bootp server be implemented on the slip >}server itself, rather than have the slip server forward the bootp request >}to some other server on the net. I implemented something like this under cslip-2.7, BSD/386, and NetBSD-0.9. The solution is something between a hack and a feature, but it is used daily by a few hundred SLIP clients. The SLIP driver watches for inbound BOOTP requests. When it sees one, it "stuffs" the IP address of the client into the appropriate fields (ciaddr & yiaddr). There is the additional overhead of checking each inbound packet, but I tried to keep it to a minimum. The approach violates the protocol layering, but a more correctly layered solution would have involved adding ioctls in other parts of the kernel. I reasoned that since I was making up for a deficiency in SLIP (lack of address negotiation), it was better to isolate the cruft to the SLIP code itself. -dpm P.S. You also need to keep the MTU higher than the BOOTP packet size since most BOOTP clients won't do fragment reassembly. -- David P. Maynard, Carnegie Mellon University & Dependable Solutions USMail: 14312 Richard Walker Blvd, Austin, TX 78728-6862 EMail: dpm@depend.com, Tel: +1 512 251 8122, Fax: +1 512 251 8308 --
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: Mon, 6 Jun 1994 07:33:37 From: CLAY@ucssun1.sdsu.edu (Robert D. Clay) To: comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Problems with Trumpet Winsock, SLIP ans UDP
I have been successful in getting Trumpet Winsock to run in internal Slip mode with one exception: I can only access hosts by IP number. When I try by name, I get the following error dump. This has me stumped. I am unable to determine why I am getting this IP checksum error. At first I thought I had my modem configured wrong, and that it was not properly doing error correction. I have ruled out this possibility. I am using LAPM. Do you have any ideas? The only clue I have is that TCP works, and UDP does not. If you can help. please reply via e-mail. Thanks. Thanks. Bob Clay ------------------------------ WSAStartup(257,1E87:4198) gethostbyname ucssun1 id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001 Ether 00:00:00:00:00:00->00:00:00:00:00:00 IP 130.191.2.30 ->130.191.224.2 len 62 prot 17 UDP 1024->53 34 00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 00 01 IP header checksum error IP header checksum error id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001 Ether 00:00:00:00:00:00->00:00:00:00:00:00 IP 130.191.2.30 ->130.191.224.2 len 62 prot 17 UDP 1024->53 34 00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 00 01 IP header checksum error id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001 Ether 00:00:00:00:00:00->00:00:00:00:00:00 IP 130.191.2.30 ->130.191.224.2 len 62 prot 17 UDP 1024->53 34 00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 00 01 IP header checksum error (This continues for quite awhile) Robert D. Clay San Diego State University Data Communications Manager Telecommunications and Network Services 619/594-7309 (Voice) San Diego, CA 92182 619/594-2912 (FAX) Robert.Clay@sdsu.edu (Internet)
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: Mon, 6 Jun 1994 03:29:35 GMT From: venu@voodoo.utcc.utk.edu (Nair Venugopal) To: comp.protocols.tcp-ip,comp.security.unix Subject: Is IP source routing a bad idea?
Hi,
Apologies, if these are newbie questions.
IP level options are disallowed in the post BSD 4.3 rlogin/rsh daemons and
in the tcp wrappers package,
The tcp wrapper man page says that
"tcpd disables source-routing socket options on
every connection that it deals with. This will take care of
most attacks from hosts that pretend to have an address that
belongs to someone elses network."
1) How can rlogind or rshd be compromised if the source routing is enabled?
(If some one tries to spoof a host on another network, wouldnt the
intermediate routers reject the spoofed packets.)
2) Is there any situation, other than trouble shooting, where
the source routing option will be of use?
3) Are the rlogind/rshd daemons in SunOS 4.1.x susceptible to source
routing attacks?
4) Is there any patch for fixing the getsockopt() system call bug in
SunOS 4.1.x ?
Thanks
Venu
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 14:17:58 -0400 From: mharrop@interlog.com (Matt Harrop) To: comp.protocols.tcp-ip Subject: Multi-homed host
I am currently moving from one provider to another. During the move, I would like to maintain my primary nameserver, so I need to keep at least one IP address the same. My current IP address is 199.0.20.47. This is from my current providers network. I'd like to keep that address (my nameserver is at that address) _and_ put the same machine on an ethernet that is routed to my new provider. The one machine would then have two IP addresses, each on networks that connect to different providers. I can then have the NIC transfer my nameserver to the new address and once that's done, be rid of the old IP address. I've never delt with a host on two networks; will this cause a problem? If so, how can I pull of this switch? Cheers, -- Matt Harrop mharrop@interlog.com InterLog Internet Services voice (416) 537-7453 fax (416) 532-5015 Online Publishing, Marketing, and Support on the Internet Coming in July -- Lowest Cost Dial-Up Internet Connectivity in Toronto
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 08:10:59 GMT From: casper@fwi.uva.nl (Casper H.S. Dik) To: comp.protocols.tcp-ip,comp.security.unix Subject: Re: Is IP source routing a bad idea?
venu@voodoo.utcc.utk.edu (Nair Venugopal) writes: >Apologies, if these are newbie questions. >IP level options are disallowed in the post BSD 4.3 rlogin/rsh daemons and >in the tcp wrappers package, >The tcp wrapper man page says that > "tcpd disables source-routing socket options on > every connection that it deals with. This will take care of > most attacks from hosts that pretend to have an address that > belongs to someone elses network." >1) How can rlogind or rshd be compromised if the source routing is enabled? > (If some one tries to spoof a host on another network, wouldnt the > intermediate routers reject the spoofed packets.) No, because the packets are source-routed. They will only be rejected if the router is configured to reject source routed packets or to reject packets coming from anotehr interface than expected. (I.e., if you have an interface with a subnet associated, you should reject all packets coming into the router from any of the other interfaces that have a source address on that one interface.) >2) Is there any situation, other than trouble shooting, where > the source routing option will be of use? Not many, though as work-around for temporary routing failures, it can be useful. But even that is mostly under the heading of trouble shooting. >3) Are the rlogind/rshd daemons in SunOS 4.1.x susceptible to source > routing attacks? As far as I could determine, SunOS 4.1.x machines with only one ethernet interface are not susceptible to a source routing attack. It think this is because the source routed code requires that a source routed packet leaves another interface than the one it came in on. Anyway, I couldn't get any of our SunOS machines react to source routed packets. I could get our Solaris 2.x machines react to source routed packets. I could be wrong about SunOS, though, so switching of source routing through tcpd is better. >4) Is there any patch for fixing the getsockopt() system call bug in > SunOS 4.1.x ? Yes, patch 100804-03. Casper
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 94 15:53:18 From: billw@glare.cisco.com (William ) To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
Will a telnet connection ever establish the circumstances necessary to get "quick retransmit" to work? (This would be implementation specific, I think. "quick retransmit" would normally be of value in a stead-state connection where the ACK are clocking out new data. A typical telnet connection will never reach steady state, effectively getting stuck at the beginning of "slow start" and staying there.) BillW
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 11:33:57 GMT From: jfguilla@imag.fr (J-F Guillaud) To: comp.protocols.tcp-ip Subject: No archive site for this group???
Last week, I ask for the name of the archive site for this group.
The location is not in the FAQ.
I haven't received any answer. Could someone please reply.
Thank you in advance
Jean-Francois
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: Mon, 6 Jun 1994 11:42:53 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
> Back to the issue. My understanding of TCP retransmissions has now been > enhanced as follows: > > 1) Sender measures round trip response time > > More? > 2) Sender setsretransmit timeout (RTO) to 2x RTT (or more?) Actually RTO = srtt + 4*rttvar, where srtt is the smoothed RTT estimate and rttvar is the smoothed mean deviation estimator. > 3) RTO varies depending on future RTT And mean deviation. Adding in the deviation is critical for accurate estimates on WANs. Check out the figure in Jacobson's 1988 paper for a comparison of this versus the original RFC 793 technique (which just used the mean). > 4) Sender sends packet and sets retransmission timer > > 5) Sender continues to send packets as long as there is available > window and RTO seconds have not expired, unless: > > 6) However, if: > a) RTO seconds expire before receiving ACK > > -or- > > b) Three (may vary?) duplicate ACKs received from receiver The magic number 3 is configurable (a kernel variable), but I wouldn't recommend changing unless you have a specific reason for doing so. > then: INITIATE RETRANSMIT > > Is this more accurate? Yes. Again, the reason for the "fast retransmit" (3 dup ACKs) is to initiate a retransmission *before* waiting for the retransmission timer to expire, as you'll often get the 3 dup ACKs long before the timer expires. Rich Stevens
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 12:15:27 GMT From: barryf@iol.ie (Barry Flanagan) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,vmsnet.networks.tcp-ip.misc Subject: Re: Put/Get files on PC (in a TSR, under DOS, while running another program
Joakim Rastberg (jor@krynn.solace.mh.se) wrote:
: Goddag
: Does anyone have a Terminate-and-Stay-Resident (TSR) version of ftpd
: for any standard TCPIP-stack under DOS?
: I need to put/get/delete files on a PC that is simultaneously running
: a data acquisition program.
: No, I cannot use Windows in this case, the application is Rational DOS4GW
: 32bit extended (methinx Windows don't allow that:-)
DESQView would handle the background FTP, though I am not sure about the 32bit
extended.
-Barry
--
***********************************************************************
IRELAND ON-LINE, West Wing, Furbo, Galway, Ireland
Tel: +353 (0)91 92727 : Fax: +353 (0)91 92726
IOL Internet Services - Dublin: 671-5185 : Galway 92711
-----------[000106][next][prev][last][first]----------------------------------------------------
Date: Mon, 6 Jun 1994 12:52:27 GMT
From: frontline@cix.compulink.co.uk ("Frontline Distributi")
To: comp.protocols.tcp-ip
Subject: FTPd Variants for SunOS
Can someone please recommend an FTPd variant for SunOS v4.11 ?
I am making do with the one as supplied by Sun at the moment and
although I have seen many alternatives, would like to know which are the
better ones.
Facilities I would like include
* detailed logging of FTPs
* reverse DNS "authentication"
* messages per CWD (.CWDmessage.TXT, etc)
Cheers ... Chris Miles
-------------------------------------------------------------------
Chris Miles | EMail: cmiles@frontline.co.uk
Frontline Tech Supp Centre | cmiles@cix.compulink.co.uk
Hampshire House, Wade Road | CIS : 100065,621
Basingstoke, Hampshire | Tel : +44 (0)256 847220
ENGLAND, RG24 8PL | Fax : +44 (0)256 847900
-------------------------------------------------------------------
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: Mon, 6 Jun 94 21:29:00 -0500 From: baldwinl@delphi.com To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
William <billw@glare.cisco.com> writes: >think. "quick retransmit" would normally be of value in a stead-state >connection where the ACK are clocking out new data. A typical telnet In this context, what do you mean by steady state and "clocking out new data"? >connection where the ACK are clocking out new data. A typical telnet >connection will never reach steady state, effectively getting stuck at >the beginning of "slow start" and staying there.) This almost seems like what I'm seeing. The following is a summary of a client PC with an established telnet session to a Sun Sparc. Both are on a local 10Mbps token ring. 1) I hold down "j" key on Pc 2) "j" gets sent to Sun and immediately echoed back. Round trip response is about 50ms (10ms of transit time and 40ms of delayed ACK by the PC) 3) About once every minute, Sun receives "j" packet into its adapter but does not pass it to the higher layer applications. Thus, TCP on the Sun does NOT receive the packet--it therefore does NOT send an ACK. 4) The client PC eventually sends the dropped packet, but it takes 1400ms fromthe time it originally sent the packet. On a local token ring, how could the PC have ever arrived at a retransmit timeout value of 1400ms? Is it because fast retransmit does not function for telnet session, or is it simply that the PC client is not following protocol?
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 13:50:32 GMT From: john@iastate.edu (John Hascall) To: comp.protocols.tcp-ip Subject: Re: bootp and SLIP?
In article <BILLW.94Jun6004736@glare.cisco.com>, William <billw@glare.cisco.com> wrote: } A customer inquired about using bootp to receive his nodes } parameters (hostname, netmask, etc..) when dialing in on } a SLIP connection. } } Is this possible? } I thought that bootp needed a hardware address to work. } }Some SLIP servers can support this by using the particular async port to }"imply" a hardware address. (eg, you only really need a HW address to }differeniate between hosts on a broadcast network like ethernet.) This }does pretty much require that the bootp server be implemented on the slip }server itself, rather than have the slip server forward the bootp request }to some other server on the net. If the host already knows its IP address (say, either hardwired or obtained from the SLIP login script), then many bootp servers can answer its request by looking it up via its IP address (ignoring the hardware address field). The CMU bootp server does this (as I recall). John -- John Hascall ``An ill-chosen word is the fool's messenger.'' Systems Software Engineer Project Vincent Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 15:00:55 GMT From: kwalters@PBS.ORG (Ken Walters) To: comp.protocols.tcp-ip Subject: Re: hp-ux startup files and hp-vue
I may be able to help you concerning question #1. Forgive me if you have already done this. Make sure you .profile file has the following line in it: ENV=$HOME/.kshrc export ENV P.S. There is a comp.sys.hp.hpux news group that might provide you with more responses. ------------------------------------------------------------ Ken Walters kwalters@pbs.org Made possible by the generous support of viewers like you... ------------------------------------------------------------
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: Mon, 6 Jun 1994 15:44:40 GMT From: braun@wc.novell.com (Karl Tunnell-Braun) To: comp.protocols.tcp-ip Subject: Re: Wierd netork behaviour
In article <2sgm37$jn5@hq.hq.af.mil> rwoodard@pafosu2 (Robert Woodard) writes: >Mathias Koerber (mathias@solomon.technet.sg) wrote: >: Hi there. >: I am at my wit's end. >: I have a local network (Thin Ethernet) with Ahh. Enough said :). From your problem description (see original article) I'd say you have a bad terminator somewhere. Take your Ohm meter and start a binary tree test down the wire. You will probably find either a problem in the cable above the IBM machines, or a bad terminator at either the first IBM machine, or the host above it. Good luck. -- Karl Tunnell-Braun 408/577-7301 braun@novell.com LAN Engineer Novell IS Lan Eng. "That which does not kill us, makes us stronger" - Nietzche
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: Mon, 06 Jun 1994 16:28:44 GMT From: garyrich@qdeck.com (Gary Rich) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,vmsnet.networks.tcp-ip.misc Subject: Re: Put/Get files on PC (in a TSR, under DOS, while running another program
In article <2sv40v$6v@barnacle.iol.ie> barryf@iol.ie (Barry Flanagan) writes: >Joakim Rastberg (jor@krynn.solace.mh.se) wrote: > >: Goddag >: Does anyone have a Terminate-and-Stay-Resident (TSR) version of ftpd >: for any standard TCPIP-stack under DOS? >: I need to put/get/delete files on a PC that is simultaneously running >: a data acquisition program. >: No, I cannot use Windows in this case, the application is Rational DOS4GW >: 32bit extended (methinx Windows don't allow that:-) > > >DESQView would handle the background FTP, though I am not sure about the 32bit >extended. Should be no problem at all. The Rational DOS4GW is a VCPI based DOS extender that's *very* well known to us. I use it and apps that use it in DV and DVX constantly. If you set this up with DESQview rather than DESQview/X you will probably want to contact us (support@qdeck.com) about virtualizing whatever network transport you are using. If you use DESQview/X then you can just use the included TCP/IP stack and have your ftp daemon always running. FWIW, the DOS4GW app should run in WIN/S, but not in WIN/3 unless it can use DPMI memory instead of VCPI. +--------------------------------------------------------------------------+ | Quarterdeck Office Systems ____________________/_ | | Gary Rich _________________///__\ | | _____________________________________________ ______________/////___\ | | Anonymous FTP site = qdeck.com ___________///////____\ | | ---For--- ---Write to--- ________/////////_____\ | | Pricing/Ordering info : info@qdeck.com _____///////////______\ | | Technical Questions : support@qdeck.com __/////////////_______\ | |<A HREF="http://www.qdeck.com/">Our home page</A>\\\\\\\\\\\\\\\\\\\\\\\ | +--------------------------------------------------------------------------+ You all know that Quarterdeck isn't responsible for my ramblings, right?
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 16:28:57 GMT From: john@iastate.edu (John Hascall) To: comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Problems with Trumpet Winsock, SLIP ans UDP
In article <CLAY.12.00078FAA@ucssun1.sdsu.edu>, Robert D. Clay <CLAY@ucssun1.sdsu.edu> wrote: }I have been successful in getting Trumpet Winsock to run in internal Slip mode }with one exception: I can only access hosts by IP number. When I try by }name, I get the following error dump. This has me stumped. I am unable to }determine why I am getting this IP checksum error. At first I thought I had }my modem configured wrong, and that it was not properly doing error }correction. I have ruled out this possibility. I am using LAPM. Do you }have any ideas? The only clue I have is that TCP works, and UDP does not. } }If you can help. please reply via e-mail. Thanks. } }Thanks. } }Bob Clay }------------------------------ }WSAStartup(257,1E87:4198) }gethostbyname ucssun1 }id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001 }Ether 00:00:00:00:00:00->00:00:00:00:00:00 }IP 130.191.2.30 ->130.191.224.2 len 62 prot 17 }UDP 1024->53 34 }00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 }73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 }00 01 }IP header checksum error }IP header checksum error }id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001 }Ether 00:00:00:00:00:00->00:00:00:00:00:00 }IP 130.191.2.30 ->130.191.224.2 len 62 prot 17 }UDP 1024->53 34 }00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 }73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 }00 01 }IP header checksum error }id=0001 fl=0100 ucssun1.sdsu.edu 0001 0001 }Ether 00:00:00:00:00:00->00:00:00:00:00:00 }IP 130.191.2.30 ->130.191.224.2 len 62 prot 17 }UDP 1024->53 34 }00 01 01 00 00 01 00 00 00 00 00 00 07 75 63 73 }73 75 6E 31 04 73 64 73 75 03 65 64 75 00 00 01 }00 01 }IP header checksum error } }(This continues for quite awhile) } }Robert D. Clay San Diego State University }Data Communications Manager Telecommunications and Network Services }619/594-7309 (Voice) San Diego, CA 92182 }619/594-2912 (FAX) Robert.Clay@sdsu.edu (Internet) -- John Hascall ``An ill-chosen word is the fool's messenger.'' Systems Software Engineer Project Vincent Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: Mon, 6 Jun 1994 17:04:39 GMT From: gregc@stealth.ml.com (Greg Caldwell) To: comp.protocols.tcp-ip Subject: Help with SunNet Manager beeper facility
Question
1) Is there a command line option to run SunNet Manager
2) Can I bring up a second invocation if one gui is already running?
3) I have a problem with multiple beeps when my system(s) reboot.
I appreciate any expierences you have had in this area.
---
####
(o o)
+--------------------------oooO---(__)---Oooo-----------------------------+
| |
| Gregory Caldwell,Systems Architect INTERNET : gregc@ml.com |
| Security Pricing Systems |
| Merrill Lynch TELEPHONE: (212)449-0220 |
| New York, York 10281-1309 FAX : (212)449-8612 |
+-------------------------------------------------------------------------+
|| ||
(__) (__)
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: 06 Jun 1994 19:43:24 GMT From: siedelbe@steam.ucar.edu (Gregory M. Siedelberg) To: comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: mac layer addresses
Hi all, Just a question on a topic that probably has been beaten to death in the past. Someone is trying to bridge two nets together using a bridge that is also connected to an fddi ring. Some of the computers in question have two ethernet interfaces(Suns). When each one of the nets is connected into this bridge, it complains that it sees the same MAC layer address on two different ports, no surprise. When I tell this person that this should not be done, ie., bridging two separate nets onto the same net is not proper, I get a lot of, "who says" and "show me where it says that" replies. Sun does provide a feature that one can arbitrarily change the MAC address, but only provides one address per machine and that is burned into the sun id prom. So these are the questions that I hope some of you will have the answeres to. 1. what is the publication that sets out the rules why tcp-ip networks can have only logical net per physical net, if that is indeed true? 2. where is it spelled out on how to use bridges and MAC layer addresses? I suspect that this is probably in 802.1, but don't have a copy yet to look it up, but any other references would be appreciated. 3. who owns mac addresses? who is the authorized grantor of mac layer addresses? I suspect that this is the IEEE. If someone were to just invent an address and use it are they violating any patent/trademark/copyrights/ license issues. Yes, I am trying to be technical here. I like to look at the worst case and go from there. What is happening here is that we are trying to put together a network correctly and not use quick fixes like having to set all the second enet interfaces to different mac layer addresses on all machines that span two networks. I am thinking now that a router should have been puchased instead of a bridge. Thanks so much to you-all for any thing you might send to reference this. see ya, mike
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 20:58:17 GMT From: dauns@andrews.edu (Frank Dauns) To: comp.protocols.tcp-ip Subject: pcnfsd for SCO3.2V4.2
I would like to get a PCNFS daemon for SCO3.2V4.2. Unfortunately this machine doesn't have the development set so doesn't have a compiler. Are there any FTP sites where I can obtain this binary ? Thanks in advance. -- Frank Dauns Programmer/Support dauns@andrews.edu Lake Michigan College
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 94 21:03:33 GMT From: chrisc@fir.canberra.edu.au (Chris Chlap) To: comp.protocols.tcp-ip Subject: Re: TCP over ATM reading list?
In <2ssv67$j2v@emory.mathcs.emory.edu> km@mathcs.emory.edu (Ken Mandelberg) writes: >Does anyone have a bibliography for TCP over ATM? You might like to try gopher to cell-relay.indiana.edu. They have heaps of stuff there. Also, gwen.cs.purdue.edu in /pub/atm have a collection of ATM documents. Chris Chlap University of Canberra, Australia.
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 94 21:08:23 GMT From: chrisc@fir.canberra.edu.au (Chris Chlap) To: comp.protocols.tcp-ip Subject: Re: bootp and SLIP?
In <2sughj$imn@gagme.wwa.com> greg@gagme.wwa.com (Gregory Gulik) writes: >A customer inquired about using bootp to receive his nodes >parameters (hostname, netmask, etc..) when dialing in on >a SLIP connection. >Is this possible? >I thought that bootp needed a hardware address to work. >Can someone clear this up or show how it can be done? >I've tried several configurations, but nothing works. I know >bootp works since we use it with our Xterminals. Bootp sits on top of UDP, ie. it sends UDP packets with the IP local broadcast address. Therefore, it should work over SLIP. If it doesn't, I would first check if the BOOTP server knows about the ethernet address being used in the BOOTP request being sent over the SLIP connection. It's this ethernet address which identifies the host to the BOOTP server and enables it to look up the IP address and other info for it. Chris Chlap University of Canberra, Australia. >-- >Gregory Gulik greg@wwa.com http://gagme.wwa.com/~greg >Computing Engineers, Inc. Home of WorldWide Access (SM) >Data: +1 312 282 8605 +1 708 367 1871 Voice: +1 708 367 1870 >Info: info@wwa.com Support: support@wwa.com
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 22:56:05 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: mac layer addresses
In article <SIEDELBE.94Jun6141702@steam.ucar.edu> siedelbe@steam.ucar.edu (Gregory M. Siedelberg) writes:
>1. what is the publication that sets out the rules why tcp-ip networks can
>have only logical net per physical net, if that is indeed true?
It's not true. RFC 1122, section 3.3.4.1, specifically mentions the
possibility of multiple logical networks on a physical network. It admits
that the original TCP/IP designers assumed that each physical net would be
a unique logical net; however, the protocols don't actually require this.
>3. who owns mac addresses? who is the authorized grantor of mac layer
>addresses? I suspect that this is the IEEE. If someone were to just invent
>an address and use it are they violating any patent/trademark/copyrights/
>license issues. Yes, I am trying to be technical here. I like to look at
>the worst case and go from there.
IEEE hands out blocks of MAC addresses, and vendors are supposed to give
their devices numbers within their assigned blocks. I don't think there's
any "ownership" status to this, but a vendor who was contracted to provide
an interface that conforms to IEEE 802 and doesn't follow these conventions
might be in breach of the contract (just as if they didn't implement some
other aspect of the protocol). But if a site makes use of a facility for
manually setting the MAC address, I don't think this would cause any legal
problems; it might cause network management problems if another device
shows up that happens to use that address.
>What is happening here is that we are trying to put together a network
>correctly and not use quick fixes like having to set all the second enet
>interfaces to different mac layer addresses on all machines that span two
>networks. I am thinking now that a router should have been puchased instead of
>a bridge.
Yes, I think so, too.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 23:38:13 GMT From: cliu@cs.sunysb.edu (Cheng-mean Liu) To: comp.protocols.tcp-ip Subject: Old FAQ?
Hi Folks:
Could anyone show me how to get old FAQs ?
Soccer
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: Tue, 07 Jun 94 11:55:22 -0700 (PDT) From: KCARPENT@mindlink.bc.ca (Ken Carpenter) To: comp.protocols.tcp-ip Subject: Limiting IP Broadcasting
I am trying to find a way to limit the number of packets generated when performing a broadcast over an internetwork of Ethernet subnets. Before now, we strictly limited networks to be normal trees with no cycles. However, now, we would like to be able to have redundant loops in the network, primarily in case the main link goes down. The problem is that we were using a flooding algorithm for broadcasting over all the subnets (using a proprietary network protocol). This worked fine, the gateways simply forwarded the incoming broadcast onto all other subnets. In the presence of loops, however, an enourmous number of packets will be generated unless the Gateway can be smarter about forwarding the broadcasts. I have considered a hop count, but this will still generate more traffic than desired. Also, I have looked at having the Gateway maintain some kind of list of the last time it received a broadcast from each host (part of the routing table?), and a unique identification (packet ID) from the broadcast packet. Then when a broadcast packet is received, if its packet ID is less than the packet ID in the list associated with the sending host (within some delta, and watching for wrapping), then don't forward the packet. This has the possible disadvantage of a Gateway not forwarding a legitimate packet if the right sequence of events occurs. If anyone has solved this problem before (as I am sure someone MUST have), please enlighten me either here, or via email. Thanks, Ken Carpenter Network Group R&D Delta Controls
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 01:18:20 GMT From: paulf@panic.Eng.Sun.COM (Paul Fronberg [CONTRACTOR]) To: ba.internet,alt.bbs.internet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.os.ms-windows.networking.tcp-ip,comp.protocols.ppp,comp.unix.solaris,comp.unix.programmer Subject: SVNet meeting 6/15/94: PPP, evolution, state, and direction
SVNet Meeting/Program, Wednesday, June 15, 1994 7:30pm, Mountain View (FREE)
**********************************************
* *
* PPP, Evolution, State & Directions *
* *
**********************************************
WHAT: PPP, Evolution, State & Directions
With the exposive interest in the Internet, so has grown the interest in
internetworking-related protocols, particularly PPP.
PPP, seen as many as the successor to SLIP (Serial Line IP), allows TCP/IP
connections across serial lines, such as typical analog modem connections
across voice-grade telephone lines. Our speaker will talk about the
evolution of PPP, the basic concepts behind PPP, the current state-of-the-art
in PPP, and the direction of PPP development.
WHO: Brian Lloyd, Lloyd Internetworking
Brian Lloyd is the co-author of RFC-1334 (PPP authentication), is co-author
of the PPP inverse multiplexing draft document (multilink), and is past
chairman of the IETF PPP working group. His company, Lloyd Internetworking,
is actively involved in development of PPP software for a number of different
systems.
WHEN: Wednesday, June 15, 1994 at 7:30pm
(We meet regularly on the 3rd Wednesday of each month)
WHERE: Sun Microsystems Bldg 6, 2750 Coast Avenue, Mountain View
Coast Ave appears to be just a driveway next to Bldg 5 on Garcia Ave
between Amphitheatre Pkwy and San Antonio, so don't get confused.
FOR MORE INFORMATION: please call either Paul Fronberg at (415) 366-6403
or Ralph Barker at (408) 559-6202.
FUTURE TALKS:
July 20th 1994 - Bill Jolitz on the 386BSD 1.0 release.
---------------+--------------------
SVNet is a UNIX and open systems user group supported by
member dues and donations.
SVNet Meetings are FREE and OPEN TO THE PUBLIC.
UNIX is now a registered trademark of X/Open
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: 6 Jun 1994 23:23:59 +0200 From: wietse@wzv.win.tue.nl (Wietse Venema) To: comp.protocols.tcp-ip,comp.security.unix Subject: Re: Is IP source routing a bad idea?
casper@fwi.uva.nl (Casper H.S. Dik) writes: >>3) Are the rlogind/rshd daemons in SunOS 4.1.x susceptible to source >> routing attacks? >As far as I could determine, SunOS 4.1.x machines with only one ethernet >interface are not susceptible to a source routing attack. >It think this is because the source routed code requires that a source >routed packet leaves another interface than the one it came in on. I must disagree here. Read the BSD/NET1 or NET2 code again. The number of interfaces does not matter (as long as it is > 0). Reading kernel source for breakfast is a nice way to begin the day :-) Wietse
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 05:54:07 GMT From: dhesi@rahul.net (Rahul Dhesi) To: comp.protocols.tcp-ip,comp.security.unix Subject: Re: Is IP source routing a bad idea?
In <BILLW.94Jun5234622@glare.cisco.com> billw@glare.cisco.com (William ) writes: >A correct and bug-free implementation of IP source routing allows >any host on the internet to masquerade as any IP address that it would >like to... I am a little puzzled about this. How do you arrange for replies to come back to you? -- Rahul Dhesi <dhesi@rahul.net> also: dhesi@cirrus.com
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 94 14:59:55 -0500 From: Peter Chapman <bankrupt@delphi.com> To: comp.protocols.tcp-ip Subject: Connecting the PC to the Internet
Okay . . . here goes. Can someone direct me to a source for connecting my lonesome extra 386 machine to the Internet so that other people can FTP or TELNET to my machine to retrieve certain law-related information at no charge. I'd love to put some information out on the Information Highway for others to see and use, but I can't figure out where to begin. A book entitled "How to connect a PC to the Internet over the phone lines in 100 easy steps" would be really convenient. Any ideas?
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 94 07:19:43 GMT From: jkay@cs.ucsd.edu (Jon Kay) To: comp.protocols.tcp-ip Subject: Re: Way for faster IPC than TCP/IP ?
adiwan@bbn.com (Arif Diwan) sez: > hzhou@cs.utk.edu (Honbo Zhou) writes: > >I would like to know if there is a way to do faster IPC between processes > >on different machines than TCP/IP. > > Why would you want to do that? You will probably not gain much over UDP > let alone RAW IP. I can get close to wire speed no loss thruput over > Ethernet or FDDI using the TCP/IP stack (UDP). The limiting factor is > your hardware (interface card + bus etc) and your OS. There is more than one kind of performance. He may be interested in latency rather than max throughput. This is quite common because it is the form of performance that limits RPC-style interactions. In that case, host software is firmly the bottleneck. Even at 10,000 pps throughput, if the processing latency were as low as 100 usec (which it won't be because there's no hysteresis aiding the latency case), which is quite good for a workstation, you'd see nearly half a millisecond's worth of round-trip latency. Oh: the answer is to the original question is, on Unix, unfortunately not. If you have administrative control over your own computer, you might look into installing BPF (comes with the tcpdump package), which might or might not be faster than TCP/IP. But then you'll have to roll your own transport protocol and reliability gunk. Not recommended. Jon
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 08:26:23 GMT From: eb@iunet.it (Enrico Badella) To: comp.os.linux.misc,comp.os.linux.development,comp.os.linux.help,comp.protocols.tcp-ip Subject: Broadcast address on raw sockets return EACCES
When I try to ping from my linux box a broadcast address (193.42.2.255) to see what hosts will reply I get the error sendto: permission denied. I looked at the network code (kernel 1.1.0) and found only 3 places where EACCESS is returned; in udp.c (udp_connect, udp_sendto) and sock.c (inetbind). I would exclude udp.c since ping uses a SOCK_RAW socket; in sock.c the error is returned if the usere isn't root and the port is priviledged, none of which are true when I try to ping. All other Oses I have around (SunOS, Solarisx86, SCO, HP_UX) permit this operations and I receive several replies from the network. I did notice the comment in udp.c that says that you must turn on broadcast first but I'm not sure if this applies to raw sockets. Can someone show me what I'm doing wrong? ================================================================================ Enrico Badella email softstar@pol88a.polito.it Soft*Star s.r.l. eb@vax.cnuce.cnr.it Via Camburzano 9 phone +39-11-746092 10143 Torino, Italy fax +39-11-746487 People are strange When you're a stranger (J. Morrison) ================================================================================
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 20:53:24 -0600 From: thayne@xmission.com (Thayne Forbes) To: comp.protocols.tcp-ip Subject: Re: NetManage Chameleon for Windows and SLIP
Ramzi BAROODY (rbaroody@cs.mcgill.ca) wrote: :> Hello, :> I am trying to use NetManage's Chameleon (version 3.10) TCP/IP for Windows :> to connect to Internet through a SLIP address. However, the problem :> is that Chameleon keeps insisting on dialing the phone number and connecting :> automatically using a simple script language. I can never seem to get :> connected, probably because the connection procedure on the SLIP server :> side is a bit complicated. Is there a way I could connect manually? Or :> maybe I could connect through another dialer and then have Chameleon take :> over from there? The manual was not much of a help. I would appreciate :> any suggestions. Well, at the risk of blasphemy, I would suggest that you might use Trumpet Winsock as a debugging tool. It allows just this sort of debugging, all the way up to putting the IP number in, and handing over the connection to the SLIP process. This may be sub-optimal, but it worked for me. I use it whenever trouble crops up. -- Thayne Forbes thayne@xmission.com Computer Weenie no longer at large
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 12:05:16 GMT From: wklaus@relay.nswc.navy.mil (oanews) To: comp.protocols.tcp-ip Subject: Info request 3-Tiered Architecture
I am looking for information on Triple tiered client/server architectures
(or 3-tiered). Looking for pros and cons for this form of client/server
architecture; experiences, good or bad with implementation; identification
of products; pitfalls for the unwary; standards, documentation and references.
If you could spend a couple of minutes I would appreciate a direct reply
via Email.
Address: jlynch@relay.nswc.navy.mil
Thank you in advance.
--
######
####
(* 0)
-------------------------oooO---(__)---Oooo---------------------------
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 12:17:01 GMT From: doug@siegfried.VF.GE.COM (Doug Hughes) To: comp.protocols.tcp-ip Subject: Re: Appletalk over tcp/ip how?
In article <2e4_9406031052@calcom.socal.com>, frank@calcom.socal.com (Frank Keeney) writes: |> I can route tcp/ip over my localtalk net to allow MACs to communicate with |> the rest of the ethernet. But how can I send Appletalk over a tcp/ip-only |> WAN? What equipment/software would I need. |> |> |> -- |> Frank Keeney | E-mail frank@calcom.socal.com |> 115 W. California Blvd., #411 | Fidonet 1:102/645 |> Pasadena, CA 91105-1509 USA | UUCP hatch!calcom!frank |> | FAX +1 818 791-0578 |> | Voice Mail +1 818-791-0578 x402 Well, you can use KIP or a variant.. lots of devices support this. Cayman gatorboxes, Kinetics Fastpaths, Webster Multi-ports. Of course, you usually want tohave the same kind of device on both ends. Several devices support this in software as well. you can get UAR (unix appletalk router), or CAP (columbia Appletalk Package). Also, Cisco lets you do appletalk tunneling between two of their interfaces on a quasi interface. (e.g. show apple tunnel 0,1,etc) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Doug Hughes Internal Information Systems (NorthEast) System/Net Admin Martin Marietta, Valley Forge, PA doug@vf.ge.com doug@land.vf.ge.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The light at the end of the tunnel is the headlamp of a train"
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 94 18:06:01 From: billw@glare.cisco.com (William ) To: comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: mac layer addresses
Physical interfaces are supposed to be unique. One MAC physical
address per port, one port per MAC physical address. MAC group
addresses, of course, can be assigned to many ports.
Actually, several companies, including two of the inventors of ethernet,
seem to believe (or used to believe) that there was one MAC address per
node, regardless of how many ports there were on that node.
BillW
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 19:53:33 -0400 From: mharrop@interlog.com (Matt Harrop) To: comp.protocols.tcp-ip,comp.protocols.ppp,comp.dcom.servers,comp.sys.mac.comm Subject: Strange Macintosh<-->Unix sl/ip problem
I am having a problem with slip that I am having a great deal of trouble soving. I can't even isolate that problem. The network is essentialy this: power <------sl/ip-------->gold<---------ppp--------->internet provider power=199.0.23.2, and is a PowerBook 170 running MacTCP2.0.4 with InterSLIP version 1.02. gold=199.0.20.47, and is a BSDI bsd/386 box running sliplogin. As the diagram shows, gold is connected to my internet provider a dial up PPP link. The sl/ip link between power and gold is a null-modem cable. Whenever I try to access Internet resources from power, it is extreamly slow. If I bring up mosaic is takes 10 to 15 minutes to get a home page. FTP sessions from power also take minutes to connect. Once a file transfer starts, it moves reasonably fast. This delay does not occur when I access resources that are directly on gold. The delay only occers when going past gold out onto the internet. If I login to gold and access the internet from there, there is no delay. Now, this would point to a problem on gold, correct? BUT, if I ping power from a remote host out on the 'net, the turn around time is aobut 450ms. Considering it's going through a dial up link _and_ a 9600bps serial connection, 450ms is not bad. So, I'm stumped. I would think that the problem probably lies in the Macintosh, except that performance is just fine when I'm accessing resources local to the slip server. This points to a problem with the slip server. Perhaps the packet forwarding is very, very slow. But ping times through the server are just fine, so packets are getting through. My head hurts. Thanks in advance for any help, -- Matt Harrop mharrop@interlog.com InterLog Internet Services voice (416) 537-7453 fax (416) 532-5015 Online Publishing, Marketing, and Support on the Internet Coming in July -- Lowest Cost Dial-Up Internet Connectivity in Toronto
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 16:15:43 GMT From: bbosen@netcom.com (Bob Bosen) To: comp.protocols.tcp-ip,comp.security.unix Subject: Re: ftp ACCT feature?
news@vdd.VLSI.LL.MIT.EDU wrote: : I need to implement the account (ACCT) feature of ftpd in the : wu-archive source of ftpd, in order to require an extra security : password before the user is allowed to do anything. Has anyone done : this? Its the yacc stuff I'm not sure of, and how it should fit with : the PASS command. : George Young, Rm. B-169 young@vlsi.ll.mit.edu : MIT Lincoln Laboratory young@vdd.vlsi.ll.mit.edu : 244 Wood St. [129.55.11.1] : Lexington, Massachusetts 02173-9108 (617) 981-2756 If you have an IBM PC with a VGA display, you might enjoy taking a look at my animated tutorial software on this subject. Just ftp to: ftp.netcom.com Then cd to: /pub/bbosen/Enigma/Tutorials/Vga/Grasp/Firewall and get everything that's there. The readme file should make it clear how to proceed from that point. Enjoy! -- Bob Bosen Enigma Logic Inc. 2151 Salvio St. #301 Concord, CA 94520 USA Tel: +1 510 827-5707 Internet: bbosen@netcom.com ************************************************************************** * "It wasn't me!!! Somebody must have captured my username/password!!!" * **************************************************************************
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 16:51:14 GMT From: koning@koning.enet.dec.com (Paul Koning) To: comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: mac layer addresses
In article <SIEDELBE.94Jun6134324@steam.ucar.edu>, siedelbe@steam.ucar.edu (Gregory M. Siedelberg) writes:
|>2. where is it spelled out on how to use bridges and MAC layer addresses? I
|>suspect that this is probably in 802.1, but don't have a copy yet to look it
|>up, but any other references would be appreciated.
Quoting from 802.1d, section 3.12 (Addressing):
... The specific MAC address used by every MAC entity
communicating across the Bridged Local Area Network shall
be unique in that network in order to specify the
addressed station unambiguously.
So, it is invalid to use the same address on multiple segments of a bridged
LAN. This is a well-known limitation; the section I just quoted both states
it and explains why it is there.
|>3. who owns mac addresses? who is the authorized grantor of mac layer
|>addresses? I suspect that this is the IEEE. If someone were to just invent
|>an address and use it are they violating any patent/trademark/copyrights/
|>license issues. Yes, I am trying to be technical here. I like to look at
|>the worst case and go from there.
There are two possibilities.
If the second bit of the address is 0 (in the "canonical" form written
address, a.k.a. the "ethernet form" that is the 02 bit in the first byte),
then the address is "universally administered". In that case, it is
supposed to be constructed from a 24-bit prefix ("OUI", "Organizationally
Unique Identifier") issued by the IEEE standards office, and a 24 bit
suffix issued by the organization that holds the OUI in question.
If the second bit is 1, then the address is "Locally administered". In
that case, the remaining bits are unspecified, and the allocation and
control of these addresses is up to local network management.
Universally administered addresses are (supposed to be) globally unique;
you should never see two interfaces with the same universally administered
address. Any implementation that does put the same universally
administered address out on multiple interfaces violates the IEEE 802
standard.
Locally administered addresses have no guarantees of uniqueness, and may
well be duplicated across organizations. They may even be duplicated
within an organization, if the administrator chooses to do so (or is
careless). That may in fact be perfectly ok, so long as the two interfaces
in question don't communicate at the datalink layer. In other words, they
must not be either on the same LAN segment, or on the same Bridged LAN.
If you want to make up addresses, make up Locally Administered form addresses.
Those are guaranteed not to clash with any Universally Administered ones.
It's up to you to make sure they don't clash with any other Locally
administered ones, of course.
If you make up addresses that are (by their form) Universally administered,
you're risking address conflicts. I haven't heard of any legal repercussions
from that, but certainly you would catch (justified) blame for breaking
things.
paul
!-----------------------------------------------------------------------
! Paul Koning, NI1D, B-16504
! Digital Equipment Co., LKG1-2/A19, Littleton, MA 01460, USA
! phone: (508) 486-7313, fax: (508) 486-5279, koning@koning.enet.dec.com
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over
! any member of a civilized community, against his will, is to prevent
! harm to others. His own good, either physical or moral, is not
! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 17:21:25 GMT From: rbaroody@cs.mcgill.ca (Ramzi BAROODY) To: comp.protocols.tcp-ip Subject: NetManage Chameleon for Windows and SLIP
Hello, I am trying to use NetManage's Chameleon (version 3.10) TCP/IP for Windows to connect to Internet through a SLIP address. However, the problem is that Chameleon keeps insisting on dialing the phone number and connecting automatically using a simple script language. I can never seem to get connected, probably because the connection procedure on the SLIP server side is a bit complicated. Is there a way I could connect manually? Or maybe I could connect through another dialer and then have Chameleon take over from there? The manual was not much of a help. I would appreciate any suggestions. Thanks Ramzi --
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 17:25:45 GMT From: fitz@wang.com (Tom Fitzgerald) To: comp.protocols.tcp-ip,comp.security.unix Subject: Re: Is IP source routing a bad idea?
> billw@glare.cisco.com (William ) writes:
> >A correct and bug-free implementation of IP source routing allows
> >any host on the internet to masquerade as any IP address that it would
> >like to...
dhesi@rahul.net (Rahul Dhesi) writes:
> I am a little puzzled about this. How do you arrange for
> replies to come back to you?
That's required for TCP. From RFC 1122:
4.2.3.8 IP Options
[...]
When a TCP connection is OPENed passively and a packet
arrives with a completed IP Source Route option (containing
a return route), TCP MUST save the return route and use it
for all segments sent on this connection. If a different
source route arrives in a later segment, the later
definition SHOULD override the earlier one.
Source routing will get even more interesting in the future.... many of the
IPng proposals depend heavily on source-routing, to the extent that you
probably won't be able to disable it on routers. If you could, the
protocols wouldn't work.
--
Tom Fitzgerald Wang Labs Lowell MA, USA 1-508-967-5278 fitz@wang.com
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 17:44:16 GMT From: apollo1@netcom.com (Doug A. Chan) To: biz.sco.general,comp.protocols.tcpip,comp.unix.admin Subject: Strange rcp/rcmd response times in SCO Unix.
I've recently discovered a strange problem with rcp and rcmd: The first time I do an rcmd to a particular machine, the response time is fairly quick but every time after that it is extremely slow. Here is what I did: $ timex rcmd SOMEMACHINE -l USER date real 3.00 user 0.05 sys 0.26 $ timex rcmd SOMEMACHINE -l USER date real 11.96 user 0.03 sys 0.20 If I wait a minute or two, the response time goes back to normal. The response of rcp is also similar... In additional, if I do the same thing to my own machine (ie. rcp or rcmd to localhost) I get the same type of wierdness! All the machines I've tested on are running SCO 3.2v4.2, TCP 1.2.1o with the latest LLI (3.3.0) driver. Is there a problem with rshd or inetd? Can anyone clue me in as to what is happening? -Doug apollo1@netcom.com apollo@world.std.com
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 18:00:09 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: Re: Voice
In article <kymaCqxK9s.93G@netcom.com> kyma@netcom.com (Matt Young) writes: > How does RSVP work, say compared to an ARP. I use ARP as an > example since it is an approximation to call set up. Is RVSP like > a call set up? Does one issue an RSVP to modify the delay and > throughput characteristics of a particular connection? As I (barely) understand it, RSVP negotiates with routers and reserves bandwidth. It is not sufficient to talk to the end nodes. You must deal with all routers in-between. > Explain a little more about STII. Is it lighter weight IP? > What does it claim to have that IP doesn't have? STII is a different IP. Advantages include bandwidth reservation. Disadvantages: it only works with STII traffic. IP traffic isn't modified, controlled or managed. Also, it doesn't interoperate. You need two stacks. Since you are going to have some IP anyway, and since STII doesn't control IP, you cannot reserve IP bandwidth. > And I assume that SNMP management will cross all layers, allowing > some semblence of uniform monitoring, if not control. I don't think this is that simple. I wouldn't allow some outside party control, monitor and reconfigure my routers and hosts. -- Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 18:34:43 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: Re: TCP/IP vs. LU 0 (tuning)
In article <dch2CqvqBH.HK8@netcom.com> dch2@netcom.com (D. Hobbs) writes: > What kind of recommendations do y'all have? If you want fast TCP, you must consider the possible causes. One cause of slowness is congestion. This is dynamic in nature, and has no "values" to tweak. Most of the decisions are in the implementation and algorithms used. Proper tuning requires replacing the algorithms, not changing constants. Another cause of slowdown is application specific parameters, like window size. Grab "ttcp" from sgi.com or brl.mil to experiment with application level parameters. A third possible cause is network failures, like dropped packets, retransmits, etc. Find the cause and eliminate these problems. Maybe it's an overloaded server or router. A fourth cause is slow implementations. ttcp will help you find the fastest throughput your system can achieve. But if it still isn't fast enough, get a faster processor or more recent software. A fifth cause is bandwidth delay. This is related to bandwith and distance. There aren't many system-level parameters. -- Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 18:44:48 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: Re: Way for faster IPC than TCP/IP ?
hzhou@cs.utk.edu (Honbo Zhou) writes: >I would like to know if there is a way to do faster IPC between processes >on different machines than TCP/IP. Why not use UDP? TCP setups take several extra packets and often require the server to fork for each new connection. Use UDP and you don't need to worry about it. You do have to worry about reliability and timeouts... -- Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 18:50:39 GMT From: zagar@chester.cms.udel.edu (Randy Zagar) To: comp.protocols.tcp-ip Subject: Re: Way for faster IPC than TCP/IP ?
In article 150723@bbn.com, adiwan@bbn.com (Arif Diwan) writes: > >Here are some figures [pps = packets/sec]: > >Ethernet (Theoretical wire speed: 10MB/s): > 8400 pps 128 byte packets -> 8.2 MB/s > 1200 pps 1024 byte packets -> 9.375 MB/s > >If I stay on just one ring or ethernet segment then I can pump very >close to wire speed - over 95%. > Pardon my incredulousness, but I find those numbers to be a little too good to believe. You're talking about ACTUAL MEASURED THROUGHPUT aren't you ? I'd also be interested in knowing what hardware/OS you were running on when you did these tests... *Some* vecdors have better implementations of IP than others... -Randy --- ____________________________________________________________________________ / \ | Randy Zagar | Voice: 302/831-1130 | | College of Marine Studies | FAX: 302/831-6838 | | University of Delaware | Internet: zagar@Chester.CMS.UDel.Edu | | Newark, DE 19711 | Compu$erve: 73072,1413 | |----------------------------------------------------------------------------| | PGP Key available on request, or by 'finger'. | \____________________________________________________________________________/
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 19:32:28 GMT From: shah@abba (Sanjeev Shah) To: comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,comp.protocols.ppp Subject: routing on a router/gateway
I have a class C address and use a UnixWare host (SVR4.2) to connect
to the internet via a dialout PPP link. The machine has two interfaces
(wd0 and ppp) and IPFORWARDING is set to 1. I am using separate IP
addresses for the two interfaces.
When I rlogin to a host on the internet, I see that I have come over the
ppp0 interface's IP. i.e. 'who' on a SunOS host shows my userid and the
IP address of ppp0 (199.xxx.xxx.3). I had really like to see this as
the IP associated with wd0 (199.xxx.xxx.2). i.e. I want the unix box
to act as a router and just pass the IP packets via the ppp0 interface.
i.e. icon->icon2->provider->internethost. Is this possible using routed?
This scenario should be true of any router (cisco, etc.) in a big
organization. I am sure their router passes the IP of the originating host
and not its own IP as the originator IP or is my case special because of PPP?
I have also tried subnetting with the same results. For subnetting
I used 199.xxx.xxx.33 for ppp0 and 199.xxx.xxx.65 for wd0 and a
netmask of 199.xxx.xxx.224. Any help is appreciated.
+----------+ [icon2] [provider] +----------+
| | ppp0 (199.xxx.xxx.3) (164.xx.xx.xx) | |
| unixware |------------------------------------------| internet | internet
| host | | provider |-------->
| | wd0 (199.xxx.xxx.2) | |
| |------+ [icon] | |
+----------+ | +----------+
|
[iconnet]
199.xxx.xxx.0
|
(planned LAN)
netstat -r
----------
Routing tables
Destination Gateway Flags Refs Use Interface
localhost localhost UH 0 0 lo0
provider icon2 UH 0 0 ppp0
default provider UG 1 1276 ppp0
iconnet icon U 0 0 wd0
--
Sanjeev Shah shah@abba.fcmc.com
--
--
Sanjeev Shah internet: shah@abba.fcmc.com
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 19:34:32 GMT From: dsiebert@icaen.uiowa.edu (Doug Siebert) To: comp.protocols.tcp-ip Subject: Re: Way for faster IPC than TCP/IP ?
zagar@chester.cms.udel.edu (Randy Zagar) writes: >In article 150723@bbn.com, adiwan@bbn.com (Arif Diwan) writes: >> >>Here are some figures [pps = packets/sec]: >> >>Ethernet (Theoretical wire speed: 10MB/s): >> 8400 pps 128 byte packets -> 8.2 MB/s >> 1200 pps 1024 byte packets -> 9.375 MB/s >> >>If I stay on just one ring or ethernet segment then I can pump very >>close to wire speed - over 95%. >> >Pardon my incredulousness, but I find those numbers to be a little too good >to believe. You're talking about ACTUAL MEASURED THROUGHPUT aren't you ? >I'd also be interested in knowing what hardware/OS you were running on >when you did these tests... *Some* vecdors have better implementations of IP >than others... Obviously they aren't measured -- you can't get more than 1.25MB (megabytes) out of Ethernet even if all 10Mb (megabits) it is capable of were totally devoted to data, with no overhead, etc., etc. Maybe he was using UDP and only measuring packets sent, rather than sent and receiving. Many current Unix workstations can send at such rates, the packets that can't be sent because of limitations of wire speed are just dropped, since UDP is unreliable. As for vendor TCP/IP, I've read/heard/seen in several places that SGI is currently tops on TCP/IP capability, followed closely by HP. Both have machines that are capable of essentially saturating an FDDI ring (100Mb/sec) Even the lowest end workstations from just about any major vendor should be able to saturate an Ethernet without any difficulty these days. (I remember seeing experiments Van Jacobsen did with highly optimized TCP/IP kernels saturating an Ethernet on a lowly Sun 3! -- Doug Siebert | I have a proof that everything I have stated above dsiebert@isca.uiowa.edu | is true, but this .sig is too small to contain it.
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 20:03:19 GMT From: mitch@cirrus.com (Mitch Wright) To: comp.protocols.tcp-ip Subject: Re: TCP over ATM reading list?
/* chrisc@fir.canberra.edu.au (Chris Chlap) writes: */ >>Does anyone have a bibliography for TCP over ATM? >You might like to try gopher to cell-relay.indiana.edu. They have heaps >of stuff there. >Also, gwen.cs.purdue.edu in /pub/atm have a collection of ATM documents. > The ATM Forum is also running an HTTP server now, so you might check that out. The URL is http://www.atmforum.com/ ~mitch
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Jun 1994 01:56:27 UNDEFINED From: treynold@fred.lasalle.edu (Tommi) To: comp.protocols.tcp-ip,comp.security.unix Subject: Re: Is IP source routing a bad idea?
In article <1994Jun6.032935.17859@martha.utcc.utk.edu> venu@voodoo.utcc.utk.edu (Nair Venugopal) writes: [stuff deleted] >The tcp wrapper man page says that > "tcpd disables source-routing socket options on > every connection that it deals with. This will take care of > most attacks from hosts that pretend to have an address that > belongs to someone elses network." >1) How can rlogind or rshd be compromised if the source routing is enabled? > (If some one tries to spoof a host on another network, wouldnt the > intermediate routers reject the spoofed packets.) Well, source routing is used to do just that... disallow routing decisions from occuring along the path. When source routing is specified, then the sender specifies the entire route that the packet should take; i.e., the routers in the middle wouldn't reject... >2) Is there any situation, other than trouble shooting, where >the source routing option will be of use? Not as far as I can think of off hand; about the only thing that I can think of/remember that source routing is used for is (as you mentioned) when troubleshooting--it can eliminate the possibility of different packets taking different routes along their merry way... >3) Are the rlogind/rshd daemons in SunOS 4.1.x susceptible to source >routing attacks? >4) Is there any patch for fixing the getsockopt() system call bug in > SunOS 4.1.x ? Sorry; OS specific (especially SUNs) stuff I really am not all that good with... Hope this helps.... --- Tommi treynold@fred.lasalle.edu The above are my thoughts; if you don't like them, don't read them!
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: 07 Jun 1994 21:05:02 GMT From: Steinar.Haug@runit.sintef.no (Steinar Haug) To: comp.protocols.tcp-ip,comp.unix.solaris Subject: Re: Way for faster IPC than TCP/IP ?
> >Here are some figures [pps = packets/sec]: > > > >Ethernet (Theoretical wire speed: 10MB/s): > > 8400 pps 128 byte packets -> 8.2 MB/s > > 1200 pps 1024 byte packets -> 9.375 MB/s > > > >If I stay on just one ring or ethernet segment then I can pump very > >close to wire speed - over 95%. > > > > Pardon my incredulousness, but I find those numbers to be a little too good > to believe. You're talking about ACTUAL MEASURED THROUGHPUT aren't you ? > > I'd also be interested in knowing what hardware/OS you were running on > when you did these tests... *Some* vecdors have better implementations of IP > than others... It should be obvious from the posting that 'B' means bit here. I like to use lowercase b for bit myself and B for Byte. However, that doesn't change the validity of the measurements. It's been several years now since I measured more than 1 Mbyte/s (1048576 byte/s) using ttcp between two Sparcstation IPC on an otherwise quiet Ethernet segment (ie only those two hosts were actrive). IPCs are not exactly fast by current standards. This is an easy test to make for yourself. I *expect* all reasonable workstation vendors nowadays to be able to saturate an Ethernet. I *hope* it won't be too long before they can all saturate an FDDI ring also. I still haven't seen anything which indicates that Suns can do this, even if several other well known workstation vendors can. Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 21:40:44 GMT From: iiitac@uk.ac.swan.pyr (Alan Cox) To: comp.os.linux.misc,comp.os.linux.development,comp.os.linux.help,comp.protocols.tcp-ip Subject: Re: Broadcast address on raw sockets return EACCES
In article <2t1avf$8lh@sgi.iunet.it> eb@iunet.it (Enrico Badella) writes: >When I try to ping from my linux box a broadcast address (193.42.2.255) to >see what hosts will reply I get the error sendto: permission denied. I looked Add the lines int bcast=1; setsockopt(socket_fd, SOL_SOCKET,SO_BROADCAST,&bcast,sizeof(bcast)); into ping so that it sets the broadcast allowed option. Alan
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 18:34:16 +0200 From: wietse@wzv.win.tue.nl (Wietse Venema) To: comp.protocols.tcp-ip,comp.security.unix Subject: Re: Is IP source routing a bad idea?
>A correct and bug-free implementation of IP source routing allows >any host on the internet to masquerade as any IP address that it would >like to... dhesi@rahul.net (Rahul Dhesi) writes: >I am a little puzzled about this. How do you arrange for >replies to come back to you? That is what the source route is for: the client specifies the route that datagrams (both ways) should take. Wietse
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: Tue, 7 Jun 1994 22:44:00 GMT From: manfredi@rockwell.com (Bert Manfredi, 747-6735) To: comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: mac layer addresses
In article <SIEDELBE.94Jun6134324@steam.ucar.edu>, siedelbe@steam.ucar.edu (Gregory M. Siedelberg) writes... > >Someone is trying to bridge two nets together using a bridge that is also >connected to an fddi ring. Some of the computers in question have two ethernet >interfaces(Suns). When each one of the nets is connected into this bridge, >it complains that it sees the same MAC layer address on two different ports, >no surprise. When I tell this person that this should not be done, ie., >bridging two separate nets onto the same net is not proper, I get a lot of, >"who says" and "show me where it says that" replies. Sun does provide a >feature that one can arbitrarily change the MAC address, but only provides >one address per machine and that is burned into the sun id prom. So these are >the questions that I hope some of you will have the answeres to. Physical interfaces are supposed to be unique. One MAC physical address per port, one port per MAC physical address. MAC group addresses, of course, can be assigned to many ports. > >1. what is the publication that sets out the rules why tcp-ip networks can >have only logical net per physical net, if that is indeed true? Check RFC 1122. You can have many logical nets on a physical net. > >2. where is it spelled out on how to use bridges and MAC layer addresses? I >suspect that this is probably in 802.1, but don't have a copy yet to look it >up, but any other references would be appreciated. Try Radia Perlman's _Interconnections_, ISBN 0-201-56332-0. It's even a fun read! > >3. who owns mac addresses? who is the authorized grantor of mac layer >addresses? I suspect that this is the IEEE. If someone were to just invent >an address and use it are they violating any patent/trademark/copyrights/ >license issues. Yes, I am trying to be technical here. I like to look at >the worst case and go from there. Yes, it is the IEEE. Perhaps someone can give you the details off the top. Bert manfredi@rockwell.com
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 23:04:53 GMT From: zhao@ERC.MsState.Edu (Xiaodong Zhao) To: comp.protocols.tcp-ip Subject: Re: Way for faster IPC than TCP/IP ?
In article 94Jun7144448@grymoire.crd.ge.com, barnett@grymoire.crd.ge.com (Bruce Barnett) writes: >hzhou@cs.utk.edu (Honbo Zhou) writes: >>I would like to know if there is a way to do faster IPC between processes >>on different machines than TCP/IP. > >Why not use UDP? TCP setups take several extra packets and often >require the server to fork for each new connection. Use UDP and you >don't need to worry about it. You do have to worry about reliability >and timeouts... > >-- >Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett I'd like to join this discussion and have been curious about how much speedup you could get by using UDP instead of TCP particularly if in a local area environment like a building. W. Richard Stevens' UNIX NETWORK PROGRAMMING shows there might be double. Any body has done any test? What about using raw packet? -Zhao ERC, MSU
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 23:12:07 GMT From: zhao@ERC.MsState.Edu (Xiaodong Zhao) To: comp.protocols.tcp-ip Subject: Re: Way for faster IPC than TCP/IP ?
In article 94Jun7230502@bokfink.runit.sintef.no, Steinar.Haug@runit.sintef.no (Steinar Haug) writes: >> >Here are some figures [pps = packets/sec]: >> > >> >Ethernet (Theoretical wire speed: 10MB/s): >> > 8400 pps 128 byte packets -> 8.2 MB/s >> > 1200 pps 1024 byte packets -> 9.375 MB/s >> > >> >If I stay on just one ring or ethernet segment then I can pump very >> >close to wire speed - over 95%. >> > >> >> Pardon my incredulousness, but I find those numbers to be a little too good >> to believe. You're talking about ACTUAL MEASURED THROUGHPUT aren't you ? >> >> I'd also be interested in knowing what hardware/OS you were running on >> when you did these tests... *Some* vecdors have better implementations of IP >> than others... > >It should be obvious from the posting that 'B' means bit here. I like to >use lowercase b for bit myself and B for Byte. However, that doesn't change >the validity of the measurements. > >It's been several years now since I measured more than 1 Mbyte/s (1048576 >byte/s) using ttcp between two Sparcstation IPC on an otherwise quiet Ethernet >segment (ie only those two hosts were actrive). IPCs are not exactly fast by >current standards. This is an easy test to make for yourself. > >I *expect* all reasonable workstation vendors nowadays to be able to saturate >an Ethernet. I *hope* it won't be too long before they can all saturate an >FDDI ring also. I still haven't seen anything which indicates that Suns can do >this, even if several other well known workstation vendors can. > >Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY >Email: Steinar.Haug@runit.sintef.no Does andybody know anything about the 100M Ethernet? How did they do that! -Zhao
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: 7 Jun 1994 23:16:18 GMT From: zhao@ERC.MsState.Edu (Xiaodong Zhao) To: comp.protocols.tcp-ip Subject: tcp/ip using for high-speed network
I'd like to people in this group to talk about the potential of using TCP/IP as a communication protocal for high-speed network. Is it good, better or best? what's advantage or disadvantage of using tcp/ip especially for high-speed network such as FDDI? -Zhao ERC, MSU
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: Wed, 08 Jun 1994 14:28:38 -0800 From: michael_munoz@smtp.esl.com (Michael D. Munoz) To: comp.protocols.tcp-ip Subject: Fetch for the Mac?
Please disregard if this is in the wrong place, can anyone tell me where I
can get a copy of " Fetch " for the mac, if you think you can help me ,
could you E-mail it to me in an enclosure.
--
******************* The above opinions are mine alone.
*********************
************* Thing are NOT always what they seem, even if they ARE.
*************
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Jun 1994 02:45:42 GMT From: barnett@grymoire.crd.ge.com (Bruce Barnett) To: comp.protocols.tcp-ip Subject: Re: Way for faster IPC than TCP/IP ?
In article <2t2uel$4qg@Tut.MsState.Edu> zhao@ERC.MsState.Edu (Xiaodong Zhao) writes: > I'd like to join this discussion and have been curious about how much speedup you could > get by using UDP instead of TCP particularly if in a local area environment like a building. > W. Richard Stevens' UNIX NETWORK PROGRAMMING shows there might be double. > Any body has done any test? What about using raw packet? Well, if you open a TCP socket, send a query, get a response, and close the socket, there will probably be 10 packets sent back and forth: # open a socket Host A Syn Host B Syn & Ack Host A Ack # Send data Host A send data Host B Ack # reply Host B send data Host A Ack #Close socket Host A FIN Host B FIN & ACK Host A ACK With UDP, it's Host A send data Host B send data --- However, if you miss a UDP packet, you have to timeout and retransmit. The UDP server must maintain state for each connection, if necessary. Also - some kernels may decide to not send UDP packets if the machine is overloaded. Using ttcp with UDP packets vs. TCP packets will demonstrate this. -- Bruce Barnett <barnett@crd.ge.com> uunet!crdras!barnett
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Jun 1994 02:59:11 GMT From: henry@zoo.toronto.edu (Henry Spencer) To: comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: mac layer addresses
In article <BILLW.94Jun7180601@glare.cisco.com> billw@glare.cisco.com (William ) writes: > Physical interfaces are supposed to be unique. One MAC physical > address per port, one port per MAC physical address. MAC group > addresses, of course, can be assigned to many ports. > >Actually, several companies, including two of the inventors of ethernet, >seem to believe (or used to believe) that there was one MAC address per >node, regardless of how many ports there were on that node. In fact, the XNS protocols demand -- or used to demand, anyway -- this situation. This is why the original DIX Ethernet spec explicitly required that it be possible to change the address of an Ethernet port from the protocol software. (To understand this, it is helpful to know that XNS folks did not have the notion of a mapping between a logical address and a MAC address: an XNS host had one 48-bit address, period.) -- "...the Russians are coming, and the | Henry Spencer @ U of Toronto Zoology launch cartel is worried." - P.Fuhrman | henry@zoo.toronto.edu utzoo!henry
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1994 03:08:37 GMT From: visser@convex.com (Lance Visser) To: comp.protocols.tcp-ip Subject: Re: Way for faster IPC than TCP/IP ?
In <2t2uel$4qg@Tut.MsState.Edu> zhao@ERC.MsState.Edu (Xiaodong Zhao) writes: +>I'd like to join this discussion and have been curious about how much speedup you could +>get by using UDP instead of TCP particularly if in a local area environment like a building. +>W. Richard Stevens' UNIX NETWORK PROGRAMMING shows there might be double. +>Any body has done any test? What about using raw packet? If you can open the tcp window large enough and have delayed acks working properly and are running checksums on both tcp and udp then the results should be similar. tcp only "stalls" when it has sent a full window and has not yet received an ack. The thing to remember about TCP is that it only starts getting expensive if you have loss on the net. You don't do timeouts or retrans missions if there is no loss.
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1994 04:07:00 GMT From: kenton@space.mit.edu (Kenton C. Phillips) To: comp.sys.sun.admin,comp.protocols.tcp-ip Subject: Sparcstation as filtering bridge?
I am trying to figure out how to use a Sun Sparcstation with two ethernet ports as a filtering bridge. That is, I would like to put one port on the backbone, and connect one or more computers to the second port, but without configuring the second port as a logical subnet (as is the more typical arrangement). There are several reasons for this, one of which is that we will be putting data acquisition machines on the second port, and we would like to be able to move those machines around without having to reassign IP addresses and reconfigure routing information with every move. If all machines on both sides of each bridging Sparcstation are seen as the same subnet, then such reconfiguration could be avoided. However, it would seem that this is a non-standard thing to do, at least as far as I can tell. Is there a way to configure the system (SunOS 4.1.3) to make it work this way, or does there exist software to do this? Thanks in advance for any advice. -- Kenton C. Phillips Computer Systems Manager MIT Center for Space Research kenton@space.mit.edu
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Jun 1994 04:32:20 GMT From: mfork@dorsai.org (Mike Forkash) To: comp.protocols.tcp-ip Subject: TCP/IP FAQ?
I'm kinda new to TCP/IP. Is there a FAQ lying around here somewhere? Thanks in advance. -- ** ** * * * *** Mike Forkash - User Deluxe * * * * * * * *\ Mfork@Dorsai.Dorsai.Org * * * * * * */ Mfork@Cyberspace.org * * * * * ***
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Jun 1994 09:35:28 From: mscarton@mudshark.sunquest.com (Mark A. Scarton) To: comp.protocols.tcp-ip Subject: Re: Info request 3-Tiered Architecture
>I am looking for information on Triple tiered client/server architectures >(or 3-tiered). Looking for pros and cons for this form of client/server >architecture; experiences, good or bad with implementation; identification >of products; pitfalls for the unwary; standards, documentation and references. The principle issue seems to be how to abstract the "business logic" of the application from both client and server, even when the server is essentially a data "sink" such as a DBMS. Done well, the idea is that you thereby reduce the algorithmic tangling of logical constructs, lowering the cost of modification and enhancement and increasing the generality of both client and server components [reuse]. My experiences with 3-tier have been positive so far. The performance penalty associated with the addtional layer must be controlled, a la Transarc's Encina or Sybase registered procedures. Squeeky clean transport and data protocol boundaries are key. The main difficulty seems to be that it takes a higher level of design[er] sophistication andit is much more difficult to convey to management, particularly upper level. Many of them just got to the point where they understand moving independentlogic components off of the primary [server] machine. An additional problem that I've faced is that you often end up wanting to use different languages and tool sets on the various platforms that require that you reimplement the same classes/methods multiple times. For example, our current client is Visual C++ on Windows. The servers are C and Sybase (with its stored procedures, triggers, and registered procedures). Much of the existing middleware is sybperl. ======================================================================== Mark A. Scarton, ABD | Sunquest Information Systems 801/278-7597, fax 278-0192 | 4505 S. Wasatch Blvd Suite 100 mscarton@mudshark.sunquest.com | Salt Lake City, Utah 84124 ========================================================================
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1994 05:33:18 GMT From: tli@cisco.com (Tony Li) To: comp.protocols.tcp-ip Subject: Re: Limiting IP Broadcasting
In article <46171@mindlink.bc.ca> KCARPENT@mindlink.bc.ca (Ken Carpenter)
writes:
I am trying to find a way to limit the number of packets generated when
performing a broadcast over an internetwork of Ethernet subnets. ...
In the presence of loops, however, an enourmous number of packets will
be generated unless the Gateway can be smarter about forwarding the
broadcasts.
If anyone has solved this problem before (as I am sure someone MUST have),
please enlighten me either here, or via email.
cisco routers have the ability to compute a spanning tree and to forward
UDP broadcasts along the spanning tree. This eliminates problems with
duplicates, allows you to have a robust topology for unicast routing, and
fail-over for limited broadcast distribution.
Tony Li
cisco Engineering
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1994 05:59:14 GMT From: shair@uiuc.edu (Bob Shair) To: comp.sys.ibm.pc.rt,comp.protocols.tcp-ip Subject: Re: Networking the old IBM RT-PC
gpalmer@blue.weeg.uiowa.edu (Gary Palmer) writes: >Does anyone have experience in networking the IBM RT-PC (model 6150) >to an ethernet network with TCP/IP? > >I have the IBM baseband ethernet card and have loaded the TCP/IP software. >The hardware diagnostics seem to indicate that there is a good connection >back to the network. But I cannot ping to/from the RT-PC. A few attempts >to ping out result in an error message and the network software shutting >down. Well, if no one else will answer... are you still down? Yes, I have done this, but not for years. As I recall, the only problem which arose frequently was having the ?interrupt level? of the card set wrong. What error message? -- Bob Shair shair@uiuc.edu Open Systems Specialist SHAIR@UIUCVMD (bitnet) Champaign, Illinois 217/356-2684
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 94 06:02:29 GMT From: ddl@harvard.edu (Dan Lanciani) To: comp.os.os2.networking.tcp-ip,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Talk won't connect (TCPIP 2.0)
[I'm cross posting this because the question comes up every few months and this is the most complete answer I've written...] In article <paulf.771021450@abercrombie.Stanford.EDU>, paulf@abercrombie.Stanford.EDU (Paul Flaherty) writes: | In a word, endianism. The original talk program (4.2bsd on a VAX) code was | endian sensitive, so big endian machines (motorola, sun) won't talk to | little endian (DEC, Intel) boxes. Annoying as heck. It's even worse than that. The original protocol was also sensitive to structure packing! The vax unix compiler aligns longs on long boundaries while the sun2/3 compiler packs them on short boundaries. Sure enough, one of the talk packets had a non-padded long. Now, a clever programmer somewhere noticed that you could usually tell (by looking at the address family field in one of the sockaddr structures) whether you were receiving vax-style or sun2/3-style packets. (The heuristic failed sometimes if the id word had a "2" byte in the wrong place. This would lead to situations where an initial talk request would return an unpleasant error about bad addresses, but subsequent requests would work.) Anyway, conditional code was added to talk/talkd so that both the sun2/3 version and the vax version could understand native packets from the other. Note that translation was done on input only--no attempt was made to respond in kind. Life was good for a while and everybody could talk to everybody else. (We can ignore the special protocol version with 16-byte user names that Harvard used for a while. We can also ignore the protocol that would have resulted by simply compiling the talk source on a pdp-11--it was easy enough to cause it to mimic a vax instead. :) Then along came the sun4. It had sun2/3-style byte order but vax-style structure packing. For reasons that I will never comprehend, Sun chose to allow sun4 talkd programs to emit ``native'' format packets, thus creating a third form of the protocol. At about that time, Sun also changed the heuristic in talk to deal with sun2/3 and sun4 cases, but not the vax case. (It's important to understand that the structure packing problem exists only in response packets while the byte order problem exists in both request and response packets. Therefore, sun4 request packets already look like sun2/3 request packets and it wasn't necessary to change talkd.) This broke several combinations that had worked before, and didn't make any new sun<->non-sun combination work. My own PC otalk/otalkd programs had always sent vax-style packets (padded) while understanding vax and sun2/3-style packets. It was simple enough to get otalk to understand all of vax, sun2/3, and sun4 responses by looking at the length of the packet in addition to the byte order. But, if you followed the convoluted explanation above, you will see that input translation alone is no longer enough. It was necessary to make otalkd send response packets that correspond to the requests that it receives. Of course, it isn't possible to distinguish a sun4-style request from a sun2/3-style request so one sends sun2/3-style responses for either. (This doesn't hurt anything since the sun4 client already has to deal with true sun2/3 servers.) At this point, I thought I had achieved complete interoperability without requiring users to pester their administrators to install ntalk on all their Suns. Alas, somehow the sun4 talkd has picked up a sign-extension bug in its byte-swapping code. The IP address will get 1-filled if its third byte has the high bit set. So the final answer is that, given the right PC talk programs, you can talk to anybody unless he/she is on a sun4 and your IP address a.b.c.d has c > 127. Dan Lanciani ddl@harvard.*
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: Wed, 08 Jun 1994 18:02:03 -0500 From: resnick@uiuc.edu (Pete Resnick) To: comp.protocols.tcp-ip Subject: Re: Fetch for the Mac?
In article <michael_munoz-080694142838@m21124.esl.com>, michael_munoz@smtp.esl.com (Michael D. Munoz) wrote: >Please disregard if this is in the wrong place, can anyone tell me where I >can get a copy of " Fetch " for the mac The home site for Fetch is ftp.dartmouth.edu. The better group to ask questions about this program is comp.sys.mac.comm. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Doctoral Student - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@uiuc.edu
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 94 09:43:44 +0200 From: ivo.drvaric@ext.uni-mb.si To: comp.protocols.tcp-ip Subject: Tcp/IP and Ethernet performance per Query
Hello ! I have a problem that i can't solve by myself. I have to make a decision between two architectures. First is Client-Server with Ethernet and TCP/IP protocol ( where we plan Etherne in the house on twisted -pair, and on digital leased lines (48Kb or 64Kb lines ) ). The second architecture is distribute environment with refreshment of central database on some delta time intervals. I would like make a calculation where parameter would be the length of longest and average query. But i would need some actual data on the length of administration data in TCP/IP protocol, then some data on Ethernet. Can somebody help me?
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: Wed, 08 Jun 1994 14:45:41 GMT From: larryp@sco.COM (Larry Philps) To: biz.sco.general,comp.unix.programmer,comp.protocols.tcp-ip Subject: Re: Problem with limited number of clients to TLI server solved
In <2t4b34$4uq@gulfa.ods.gulfnet.kw> john@gulfa.ods.gulfnet.kw (John Temples) writes: > I went through the manuals and did find a couple of kernel tunable > parameters related to TLI: NUMTIM and NUMTRW. The fact that these were > both set to 48 -- twice the number of clients I could connect -- made > me suspicious. Not heeding the manual's ominous warning that "Users > should not modify this parameter," I increased them both to 120, and my > problem was solved. You are right the ODT 3.0 manual does say that. I will report this, it is an error. Not only can you tune these, the manual tels you on page 625 that Lan Manager client raises these to 128. > SCO: If you haven't already, please fix the manuals so they A) document > the meaning of the ENOSPC return from t_open(), I will report this also. A major problem is the ENOSPC is kind of over used and that error can mean too many things. > B) Explain that NUMTRW > actually controls the number of TLI connections allowed, Actually, it was almost certainly the NUMTIM value that was biting you. The NUMTRW controls the number tirdwr modules pushed onto the stream which only happens when you want to use the read and write system calls on a TLI stream. Not many things do this. NUMTIM controls the number of timod modules, which is the kernel half of the TLI protocol, ie. the part that talks with the user space TLI library. _Every_ TLI connection needs one of these. --- Larry Philps Senior Software Engineer larryp@sco.com SCO Canada, Inc., 130 Bloor St. West, 10th floor, Toronto, Ontario. M5S 1N5 Phone: (416) 922-1937 Fax: (416) 922-2704
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1994 15:44:29 GMT From: koning@koning.enet.dec.com (Paul Koning) To: comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: mac layer addresses
In article <BILLW.94Jun7180601@glare.cisco.com>, billw@glare.cisco.com (William ) writes: |> Physical interfaces are supposed to be unique. One MAC physical |> address per port, one port per MAC physical address. MAC group |> addresses, of course, can be assigned to many ports. |> |>Actually, several companies, including two of the inventors of ethernet, |>seem to believe (or used to believe) that there was one MAC address per |>node, regardless of how many ports there were on that node. I wouldn't put it that way. What IS the case is that some protocols effectively map a node address to a particular single MAC address. Note that the standard DOES allow that (provided that the addresses are "locally administered" which at least in the case of DECnet they are). However, if you do this then you cannot bridge the multiple interfaces of a single node. That's a well-documented restriction. If you don't put bridges between the interfaces, then all this is entirely legal and reasonable. paul !----------------------------------------------------------------------- ! Paul Koning, NI1D, B-16504 ! Digital Equipment Co., LKG1-2/A19, Littleton, MA 01460, USA ! phone: (508) 486-7313, fax: (508) 486-5279, koning@koning.enet.dec.com !----------------------------------------------------------------------- ! "The only purpose for which power can be rightfully exercised over ! any member of a civilized community, against his will, is to prevent ! harm to others. His own good, either physical or moral, is not ! a sufficient warrant." -- John Stuart Mill, "On Liberty" 1859
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Jun 1994 16:28:18 GMT From: mvm@cbnewsb.cb.att.com (michael.v.murphy) To: comp.protocols.tcp-ip Subject: Deadlock situation
The project we are currently working on entails a the use of tli calls
between distrubuted machines (unix and mvs). The mvs side does updates to
a database; and when a deadlock occures it automatically kills a process. We
would like to deal with this situation gracefully, and have code the following
tli sequences:
Client Server
------ ------
t_open t_open
t_bind t_bind
t_listen t_connect
t_accept
t_snd t_rcv
t_rcv
------------- Deadlock --------------- (server process dies)
t_listen t_connect
t_accept
t_snd t_rcv
t_rcv t_snd
t_close t_close
When the deadlock occurs, the client is blocked to recieve the data and
the server sends a async disconnect after it is killed off by mvs. We want to
capture this disconnect and loop back into the listen on the same bound port
(as shown). For some reason our 2nd t_listen is failing with an "asynch event
has occured" error and t_look of 10 which maps to DISCONN (even though getstate
shows the connection is T_IDLE). Our question: is there any reason why we can't
use the connection after the server connection has been killed. Do we have to
start with a new open/bind? Any insight would be greatly appreciated...
Mike Murphy
mvmurphy@attmail.att.com
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1994 18:44:05 GMT From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian) To: comp.protocols.tcp-ip Subject: What is the MTU of FDDI?
I'm trying to get some agreement on MTU between hosts and routers on one of our FDDI rings, and I've realized that I don't know what the "appropriate" MTU should be. My understanding is that the true MTU for FDDI is 4500 bytes. However, I have found a recommended value of 4470 in an NSC router manual, I've seen defaults of 4352 on both RS/6000s and Sun 4s, and have been told that 4096 is the default for at least one router vendor. Clearly, 4096 would be a poor choice, as 4096 is a nice size for allocating memory. 4136 would be better which would account for the TCP/IP header. But since we've still got some headroom, why not bump it up so that packets with TCP/IP options don't need to be fragmented? Can anyone explain why choices like 4352 or 4470 were made. Vernon, can you tell me what SGI recommends? A popular, although not uniformly used, Ethernet MTU is 1500 bytes. Does any such MTU exist for FDDI, or is there really a lot of disagreement? Any help is, as always, greatly appreciated. mb -- Mark Boolootian booloo@llnl.gov +1 510 423 1948 Disclaimer: booloo speaks for booloo and no other.
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1994 18:59:16 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Questions about tcp-ip not in FAQ.
In article <jGTxjmoZjyGJ064yn@msen.com> brain@mail.msen.com writes:
>In APPC, most implementations provide a program launch capability similar to
>inetd server capabilities. Can someone detail how inetd works? If it uses
>RAW sockets to do special stuff, can someone point me to a text that describes
>what special functions that tcp-ip has to offer?
inetd doesn't do anything special. It just binds to all the ports in
inetd.conf, and when a TCP connection or UDP packet comes in it forks a
subprocess, dup()s the socket to the standard file descriptors, and exec's
the specified server program. I think there's a sample implementation of
inetd in Richard Stevens's "Unix Network Programming".
>I have gotten spoiled with other protocols abilities to post my semaphore
>whenever something is received from the channel. I realize that standard
>sockets does not provide this, but does anyone have an extension that does
>this? (MS/IBM/...)
You can use select() to wait for something to come in on any of multiple
sockets.
>Since my first implementation is for OS/2, followed by UNIX, I would like
>those who have done the same answer me. Is there some sample code available
>on the net that I can compile and play with to see how sockets code is
>written?
ftp.uu.net has the examples from the above book.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1994 18:59:40 GMT From: john@iastate.edu (John Hascall) To: comp.protocols.misc,comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Problems with Trumpet Winsock, SLIP ans UDP
Robert D. Clay <CLAY@ucssun1.sdsu.edu> wrote:
}I have been successful in getting Trumpet Winsock to run in internal Slip mode
}with one exception: I can only access hosts by IP number. When I try by
}name, I get the following error dump. This has me stumped. I am unable to
}determine why I am getting this IP checksum error. At first I thought I had
}my modem configured wrong, and that it was not properly doing error
}correction. I have ruled out this possibility. I am using LAPM. Do you
}have any ideas? The only clue I have is that TCP works, and UDP does not.
Well, I managed to botch my previous reply. Anyway, because
0x11 == XON == IPPROTO_UDP
this is almost a sure sign that your modem(s) is(are) dropping XON/XOFF.
Some (many? most? all?) modems have a "pass/don't pass XON/XOFF"
flags in addition to the select XON/XOFF vs hardware flow control flag.
John
--
John Hascall ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Jun 1994 19:39:55 GMT From: mccoll@cse.uta.edu (Roddy McColl) To: comp.protocols.tcp-ip,alt.winsock Subject: help with slip please
I am trying to set up a SLIP server on a Sparcstation 2, running SunOS
4.4.1. I have obtained cslip-2.7 and installed the software.
I am running Windows Sockets on a PC with ethernet and modem access,
so I am using this machine to test proper SLIP connections.
I find that under SLIP, I can only connect to the Sparc station
providing the sliplogin, but I cannot connect to any other machine on
the network, nor can I connect to the campus name server and get off campus.
When I put the winsock trace on IP packets, I see the following for
connections to the Sparcstation (129.112.104.5) from the PC
(129.112.104.129) :-
IP 129.112.104.129 -> 129.112.104.5 len 44 prot 6
IP 129.112.104.5 -> 129.112.104.129 len 46 prot 6
etc and I can launch WinQCT/Net telnet or ftp etc.
But if I try to connect to other machines on the network which have IP
addresses contained in the host tables of both Sparc and PC, I get the
following trace :-
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
.
.
.
etc with never any reply back.
I suspect that the problem is therefore with the slip running on the Sparc.
Note that my winsock setup has the Gateway as 129.112.101.254 which is
the campus Internet gateway, and the campus nameserver as
129.112.101.112 which is the campus name server. This works fine for
E-net connections.
Following sliplogin, the slip.login script executes the following
(found from echoing the execution to a disk file) :-
slifconfig sl0 129.112.104.5 129.112.104.129 netmask 0xffff0000
route -n delete default 129.112.104.129
route -n add default 129.112.104.129 1
route set default 129.112.104.129 mtu 552
I wonder if there is no understood route for packets through the Slip
server onto the network, or perhaps back from the network through the
Slip server to the PC ?
I have not set the Sparc up for dialing out, so there is no device cua0
and there is no entry for such a device in my /etc/ttytab.
Most suggestions gratefully received, and I will summarize responses
to the net if necessary.
Thanks
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Roddy McColl
Assistant Professor of Radiology
Radiology Imaging Center
UT Southwestern Medical Center at Dallas
5323 Harry Hines Blvd
Dallas TX 75235-9058
(214) 648-2910
(214) 648-4538 FAX roddy@mri.swmed.EDU
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1994 14:46:44 +0300 From: john@gulfa.ods.gulfnet.kw (John Temples) To: biz.sco.general,comp.unix.programmer,comp.protocols.tcp-ip Subject: Problem with limited number of clients to TLI server solved
I had a problem with a TLI-based server on SCO 3.2v4.1, in that I could only connect 24 clients to it before getting an undocumented ENOSPC error from t_open(). Several netters suggested I was out of file descriptors, but that wasn't the case -- the same server rewritten using sockets allowed the expected 60 clients to connect. I went through the manuals and did find a couple of kernel tunable parameters related to TLI: NUMTIM and NUMTRW. The fact that these were both set to 48 -- twice the number of clients I could connect -- made me suspicious. Not heeding the manual's ominous warning that "Users should not modify this parameter," I increased them both to 120, and my problem was solved. SCO: If you haven't already, please fix the manuals so they A) document the meaning of the ENOSPC return from t_open(), B) Explain that NUMTRW actually controls the number of TLI connections allowed, and C) removes the warning about not modifying parameters that are safe to modify. -- John W. Temples, III || Providing the only public access Internet Gulfnet Kuwait || site in the Arabian Gulf region
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: Wed, 8 Jun 1994 19:54:15 GMT From: ronf@phx.sectel.mot.com (Ron Feigen) To: comp.protocols.tcp-ip Subject: Re: NetManage Chameleon for Windows and SLIP
If you use Trumpet you can connect manually then just type "SLIP" to enter slip mode. Cameleon probably allows something similar. Why not try their support line? In article bnp@homer.cs.mcgill.ca, rbaroody@cs.mcgill.ca (Ramzi BAROODY) writes: > >Hello, > >I am trying to use NetManage's Chameleon (version 3.10) TCP/IP for Windows >to connect to Internet through a SLIP address. However, the problem >is that Chameleon keeps insisting on dialing the phone number and connecting >automatically using a simple script language. I can never seem to get >connected, probably because the connection procedure on the SLIP server >side is a bit complicated. Is there a way I could connect manually? Or >maybe I could connect through another dialer and then have Chameleon take >over from there? The manual was not much of a help. I would appreciate >any suggestions. > >Thanks > >Ramzi > >-- > >
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1994 20:01:00 GMT From: fjl0014@ucs.usl.edu (Lombardo Fernando J) To: comp.protocols.tcp-ip Subject: HELP FINDING traceroute
Hi!
I'm trying to find a program called traceroute for a friend of mine.
I was wondering if anyone out there can help me with this. Thank you
in advance...
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Fernando Lombardo
Univ. of Southwestern Louisiana EECE DA CAJUNS!!!
fjl@trakker.mcdermott.com fernando.lombardo@nola.mcdermott.com(SUMMER)
fjl0014@usl.edu f.lombardo@ieee.org
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 1994 21:45:43 GMT From: spurgeon@ccwf.cc.utexas.edu (Charles Spurgeon) To: comp.networks,comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: mac layer addresses
In article <BILLW.94Jun7180601@glare.cisco.com> billw@glare.cisco.com (William ) writes: > Physical interfaces are supposed to be unique. One MAC physical > address per port, one port per MAC physical address. MAC group > addresses, of course, can be assigned to many ports. > >Actually, several companies, including two of the inventors of ethernet, >seem to believe (or used to believe) that there was one MAC address per >node, regardless of how many ports there were on that node. Funny you should mention that, since I had just dug out one of the original papers on this from my piling system to show someone where the 48-bit addresses came from. It makes interesting reading since it lays out a vision that always views the operation of the LAN as part of a large internetwork filled with all manner of network technologies. That's an impressively forward-looking view given the state of networking in the early 1980s. (Or today, for that matter.) It's a PARC "blue-and-white" technical report by Yohen Dalal and Robert Printis entitled "48-bit Absolute Internet and Ethernet Host Numbers." OPD-T8101, July 1981 The abstract reads: "Xerox internets and Ethernet local computer networks use 48-bit absolute host numbers. This is a radical departure from practices currently in use in internetwork systems and local networks. ..." An excerpt from the main document: "We view the Ethernet local network as one component in a store-and-forward datagram *internetwork* system that provides communications services to many diverse devices connected to different networks." (emphasis theirs) The authors make it clear that they were designing for complex internets and wanted an end-node identifier that would persist for each host, to avoid the requirement that hosts be re-addressed when moved. In their view, this number would provide a host identity independent of the network addressing structure. The network address would be another number, dynamically obtained from a network server when the host required internet access. They mention the decision to use one 48-bit number per host in their summary. They also note in the paper that a host with multiple interfaces *could* have multiple 48-bit numbers, one of which was chosen to be the host's internet identity. They note that when this happens, "the mapping from internet address to local address is now more cumbersome." From the summary: "We believe that all hosts should have a unique physical host number independent of the type or number of networks to which they are physically connected. ... As a policy decision our internetwork architecture legislates that a host (multiply) connected to one or more Ethernet local networks has the same physical host number on each one. In summary, absolute host numbers have the following properties: o they permit hosts to be added to, or removed from networks on the internetwork with minimum administrative overhead. o they permit mapping internet addresses to network addresses during encapsulation without translation. o they permit the separation of routing from addressing, which is especially useful in internetworks with multihomed or mobile hosts. o they provide the basis for unique identification of files, programs and other objects on stand-alone and networked hosts. o they support multicast, or the delivery of data to a group of recipients rather than to a single physical host." -- Charles Spurgeon Campus Networking c.spurgeon@utexas.edu University of Texas at Austin (512) 471-3241 ex 265 Room COM1, Austin TX 78712
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: 8 Jun 94 22:00:18 GMT From: shuenn@tora.swdc.stratus.com (serene2) To: comp.protocols.tcp-ip Subject: link-layer multiplexing
Hi there,
Does anyone know/familiar with this concept described in rfc1122
3.3.4,
Finally, we note another possibility that is NOT
multihoming: one logical interface may be bound to multiple
physical interfaces, in order to increase the reliability or
throughput between directly connected machines by providing
alternative physical paths between them. For instance, two
systems might be connected by multiple point-to-point links.
We call this "link-layer multiplexing". With link-layer
multiplexing, the protocols above the link layer are unaware
that multiple physical interfaces are present; the link-
layer device driver is responsible for multiplexing and
routing packets across the physical interfaces.
I'm looking for any protocol, standard, rfcs, etc. might have being
developed for this concept. Please respond by email since my host doesn't
save all the news.
thanks,
-shuenn@swdc.stratus.com
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: 08 Jun 1994 22:38:54 GMT From: jtw@lcs.mit.edu (John Wroclawski) To: comp.protocols.tcp-ip Subject: Re: Voice
In article <kymaCqxK9s.93G@netcom.com> kyma@netcom.com (Matt Young) writes: : Are you talking about "live" voice or data files? Assuming you are : talking about live voice, Yes, live interactive. ... Is RVSP like a call set up? Does one issue an RSVP to modify the delay and throughput characteristics of a particular connection? That's about right, although the internet work does not focus on traditional point-to-point connections - for example it is supportive of the IP multicast "drop in" model where different people may join and leave a conversation at random times. The current draft of the RSVP protocol specification is available as an internet draft (internet drafts are the "working documents" of the internet engineering community). The file is available for anonymous FTP as "internet-drafts/draft-ietf-rsvp-spec-02.txt" on any of the IETF's archive servers. ds.internic.net is one such server, though there are better ones if you are not in the northeastern US. A nice overview article about RSVP appeared in the September, 1993 issue of IEEE Network magazine. What is used to identify a connection that has resource reservation? It must be identified in intermediate nodes, is their a resource ID associated with a particular Source-Destination IP pair? RSVP has a flexible reservation model. Using RSVP one can talk about things like "enough bandwidth for three people to talk to me at once" or "I'm talking to Bob, Carol, Ted, and Alice" or "reserve bandwidth for any one of Mike, Sue, and Sally, and right now I'm listening to Sue but please make sure the b/w is there if I want to switch to Sally later". The exact information used to identify data flows covered by a reservation depends on the type of reservation in use, although the destination IP address, protocol, and port almost always figure into it. Explain a little more about STII. Is it lighter weight IP? What does it claim to have that IP doesn't have? I would call ST-II heavier weight than IP, in that it contains within a single protocol several functions, such as routing and resource setup, that are provided by separate protocols in the IP model. It is much more traditionally connection oriented than the IP/RSVP approach. Explain the issues regarding next generation IP? Is easier IP switching an issues? How about a VCI style address option? Yes, the issue is making it easier to match up a packet arriving at a router with the state needed to process that packet. This state will be used for many things - routing, resource management, perhaps some security functions, and so on. So any mechanism that makes this lookup faster will improve performance in many ways. IP is and will remain a connectionless protocol. I don't think you'll see a "VCI style address option" in the narrow sense of the word. But, there are ways to speed up this state lookup in a quasi-connectionless environment, and some of these are being considered for next-generation IP. They revolve around making it easy for routers to cache frequently used state information, and making it easy to match an arriving packet to an entry in the cache. In that way they are quite similar to what a VCI does in a connection-oriented environment. : A number of research and advanced development projects are : demonstrating the possibilities of this technology today. The MBONE is : a large (800+ network, 20+ countries) virtual network embedded in the : internet which supports multicast distribution of audio and video : programs, among other things. Great, what form of the various directions mentioned above are they using. Is this being demoed with standard IP using the RSVP mechanism? At the moment it is being done with standard IP without using a reservation mechanism. From this experiment people are learning a lot about how to write voice applications which work well with varying resource levels and network errors. Rather than being strictly isochronous, these applications "adapt" to the level of service they are receiving at the time. This capability will continue to be important in a system with resource reservations. It will allow you to reserve (and pay for) resources sufficient to give the minimum quality you need at a given time. If you reserve more resources, the same application will give better quality. If the network is not fully loaded, the same application will give better quality. If the network is not heavily loaded, the same application will operate well with no specifically reserved resources at all (== lower cost) - this may be perfectly acceptable for, say, a quick chat among friends, even though you would want a reservation for your remote piano recital later that evening. : First, experiments over several years have demonstrated that b/w : management is not always required at the local ethernet level. You mean if someone makes a long file transfer, then my phone call isn't bashed? Don't we have to at least limit packet sizes? Is a corporation going to place critical white board activities in an environment where long file transfers shake thing up? Yes, exactly. I realise many people find this a counter-intuitive result, but we and others routinely run teleconferences on fairly loaded ethernets with good performance. This is because of the adaptive nature of the applications, as described above. This is not to say that bandwidth control mechanisms are not required in the general case. It may suggest, however, that the mechanism can provide looser control than is commonly believed. And I assume that SNMP management will cross all layers, allowing some semblence of uniform monitoring, if not control. Yes, I'd assume that SNMP will continue to be used for traditional network management functions, such as monitoring the performance of routers and hosts. cheers, -john John Wroclawski jtw@lcs.mit.edu
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Jun 1994 00:33:41 GMT From: mccoll@cse.uta.edu (Roddy McColl) To: comp.protocols.tcp-ip Subject: cslip 2.7 on Sparc 2 SunOS 4.1.1 server dropping packets
I am trying to set up a SLIP server on a Sparcstation 2, running SunOS
4.1.1. I have obtained cslip-2.7 and installed the software.
I am running Windows Sockets on a PC with ethernet and modem access,
so I am using this machine to test proper SLIP connections.
I find that under SLIP, I can only connect to the Sparc station
providing the sliplogin, but I cannot connect to any other machine on
the network, nor can I connect to the campus name server and get off campus.
When I put the winsock trace on IP packets, I see the following for
connections to the Sparcstation (129.112.104.5) from the PC
(129.112.104.129) :-
IP 129.112.104.129 -> 129.112.104.5 len 44 prot 6
IP 129.112.104.5 -> 129.112.104.129 len 46 prot 6
etc and I can launch WinQCT/Net telnet or ftp etc.
But if I try to connect to other machines on the network which have IP
addresses contained in the host tables of both Sparc and PC, I get the
following trace :-
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
IP 129.112.104.129 -> 129.112.104.1 len 44 prot 6
.
.
.
etc with never any reply back.
I suspect that the problem is therefore with the slip running on the Sparc.
Note that my winsock setup has the Gateway as 129.112.101.254 which is
the campus Internet gateway, and the campus nameserver as
129.112.101.112 which is the campus name server. This works fine for
E-net connections.
Following sliplogin, the slip.login script executes the following
(found from echoing the execution to a disk file) :-
slifconfig sl0 129.112.104.5 129.112.104.129 netmask 0xffff0000
route -n delete default 129.112.104.129
route -n add default 129.112.104.129 1
route set default 129.112.104.129 mtu 552
where ``slifconfig'' is the name of the SLIP-ready ifconfig supplied
with cslip-2.7.
Running ``slinfo'' reveals :-
if_unit if_mtu if_addr ia_net
0 552 129.112.104.5 129.112.0.0
ifa_dstaddr ia_netmask ia_subnet ia_subnetmask
129.112.104.129 255.255.0.0 129.112.0.0 255.255.0.0
and various other stats.
I wonder if there is no understood route for packets through the Slip
server onto the network, or perhaps back from the network through the
Slip server to the PC ?
Most suggestions gratefully received, and I will summarize responses
to the net if necessary.
Thanks
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Roddy McColl
Assistant Professor of Radiology
Radiology Imaging Center
UT Southwestern Medical Center at Dallas
5323 Harry Hines Blvd
Dallas TX 75235-9058
(214) 648-2910
(214) 648-4538 FAX roddy@mri.swmed.EDU
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: 9 Jun 1994 09:15:41 -0500 From: mikea@MCS.COM (Mike Andrews) To: comp.dcom.sys.cisco,comp.protocols.tcp-ip Subject: Re: IPX over PPP over serial line between CS500 and PC.
In article <CqxC18.634@freenet.carleton.ca>,
Ron Woodall <at760@FreeNet.Carleton.CA> wrote:
>
>
>In a previous article, Doug@rds.com (Doug Kaye) says:
>
>>In article <1994May31.084634.4000@vms.huji.ac.il> yehavi@vms.huji.ac.il writes:
>>> We would like to connect PC's running IPX to our network using dial-in lines
>>>with CS500 terminal server. Assuming I turn-on IPX processing on the CS500 and
>>>want to use it inside PPP, what should I do on the PC? Is there some additional
>>>software package that can be installed on the PC to enable it to pass IPX
>>>inside PPP over serial line? Our Novell people say that it is currently
>>>possible to do it only by encapsulating IPX inside IP.
>>
>>I believe your Novell people are correct. We live in that world and I don't
>>know of any IPX implementations over PPP.
>>
>> ...doug
>
>
>Hy guys: I have heard of one installation of IPX running over PPP. Gandalf
>is coming out with a router that will route IPX over PPP. For more info,
>contact HCHAYRA@gandalf.ca and he will put you on the appropriate sales type.
>
>Ron
>--
>
Telebit NetBlazers do IPX over PPP. They've had that for over a year.
The client drivers come with the NetBlazer. They spoof an ODI stack on the
client PC. You can run IPX and/or TCP/IP over that. Configuration on the client
side is menu driven and really easy to set up. The NetBlazer PPP link security
supports a cryptic challenge handshake and Kerberos along with a standard
password.
Our experience with it was that it was a bit slow, but it worked.
--
Mike Andrews mikea@Genesis.MCS.Com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=
"The chances of Sun today are...uhhhnnnhh...iffy, if that."
-Brant Miller, Chicago TV weatherman/radio DJ, 03/20/93
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: 09 Jun 1994 01:03:54 GMT From: rand@cs.UND.NoDak.edu (Douglas K. Rand) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Mobil laptops
We are starting a project this fall that will give every student a
laptop computer. We will be wiring some class rooms and labs for
Ethernet. Can anyone suggest a method of supplying dynamic IP
addressing? Inside of a single day, one lap top computer may be part
of different networks, even in different buildings.
I've read the RFCs for DHCP and it seems like the solution, but I have
yet to find an implementation. Also, does this situtation require the
cooperation of the client software? (We are looking at winsock that at
best supports BOOTP.)
Thanks in advance for any info/advice.
PS: Although we have pretty much decided on wire instead of wireless
(not set in conduit yet, though) does anyone have experience with
wireless networks in a classroom environment? The classrooms range
in size from 30 to 130 seats.
--
Douglas K. Rand rand@aero.und.nodak.edu
System/Network Administrator Scientific Computing Center -- UND Aerospace
Office: +1 701 777 2801 University of North Dakota
FAX: +1 701 777 2940 Box 9022, Grand Forks ND 58202-9022
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: 9 Jun 1994 02:37:00 GMT From: boyd@gauss.math.fsu.edu (Mickey Boyd) To: comp.sys.sun.admin,comp.protocols.tcp-ip Subject: Re: Sparcstation as filtering bridge?
Kenton C. Phillips (kenton@space.mit.edu) wrote: > I am trying to figure out how to use a Sun Sparcstation with two ethernet > ports as a filtering bridge. > [....] > If all > machines on both sides of each bridging Sparcstation are seen as the same > subnet, then such reconfiguration could be avoided. It sounds to me as though you just need a bridge (and that it is optional if it is the Sun). I really like the KarlBridge software, which turns a PC (286/16 or 386SX/DX) with two SMC Ethernet cards into a nifty filtering bridge. The software is free (they also sell turn-key units), and provides the most configurable bridge I have ever worked with. I have had two running for a couple of years now, with no problems. You do not need a monitor, keyboard, or hard disk (you do need a color monitor and a keyboard to configure it, but not on the bridge machine itself). It is available from nisca.acs.ohio-state.edu. By default, is it works as a transparent learning bridge (which would probably do the trick for you, from the above description). If you turn on the filtering options, you can bridge or pass packets on many different criteria. Depending on how busy the network is, you could take a perceptable hit in performance if you used the Sun as a bridge. Anyway, Kbridge gives you something to do with all those old PCs :-). Hope that helps. > That is, I would like to put one port on the > backbone, and connect one or more computers to the second port, but without > configuring the second port as a logical subnet (as is the more typical > arrangement). [....] > There are several reasons for this, one of which is that we > will be putting data acquisition machines on the second port, and we would > like to be able to move those machines around without having to reassign > IP addresses and reconfigure routing information with every move. A device that sits between logical subnets is typically a router or a gateway. A bridge simply looks at packets and selectively repeats them to the other port (depending on whether or not it thinks the destination machine is on the other side). Thus, its primary function is to localize traffic on either side of, while allowing communications across, the bridge. If the Sun that needs to talk to the data acquisition machines does not need to talk to other machines (as much), then bridging the Sun and the data acq. machines would make sense. -- ****************************************************************************** * Mickey Boyd * * Systems Administrator * * Florida State University Mathematics Department * * email: boyd@math.fsu.edu Office: (904) 644-7167 Pager: (904) 657-6425 * ******************************************************************************
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: Thu, 09 Jun 1994 16:09:39 -0800 From: peak@halcyon.com (Paul K. Kim) To: comp.protocols.tcp-ip Subject: Mosaic 1.0.3 for Mac problem
I run Mosaic 1.0.3 for Mac on my Powerbook with system 7.1 and MacTcp. Somehow, when I try to start sometimes, the program fails to load, making all the title bars and menu fonts huge and reporting a problem... Any hints why? -- Paul K. Kim peak@halcyon.com
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Jun 1994 10:56:50 From: CAMARA@novell.wd.cubic.com (Raland Camara) To: comp.protocols.tcp-ip Subject: HP-UX reliable signals and "Unix Network Programming"
In writing a test program under HP-UX, I have discovered some rather
disturbing results concerning the use of reliable signas and socket I/O.
Hopefully, I am just mistaken or missing some pearl of wisdom. Under HP-UX
using the sigvector() system call for setting up an interrupt handler, I have
noticed that multiple SIGIO signals are not blocked but instead are ignored.
More specifically when execution is inside of the SIGIO signal handler (setup
by sigvector()), additional SIGIO signals are ignored instead of blocked.
My understanding of reliable signals comes primarily from "Unix Network
Programming" by W. Richard Stevens. It states the following concerning
reliable signals:
"A process must be able to prevent selected signals from occurring when
desired. But we don't want a signal discarded..... Instead we want the signal
remembered, so that when we're ready the signal is delivered. 4.3BSD terms
this 'blocking' a signal and System V calles it 'holding' a signal.
While a signal is being delivered to a process, that signal is blocked (held).
By this we mean that if a signal is generated a second time, while the process
is handling its first occurrence, the signal handler is not called again.
Instead, the second occurrence of the signal is remembered. If the signal
handler that is processing the first occurrence of the signal returns
normally, only then it is called again to handle the remembered signal."
My experience seems contrary to what is described above. One other peculiar
bit of information, is in the HP publication "Berkeley IPC Programmer's Guide"
in the sample program "async.clnt.c" there exists the comment:
"Send data to the server over the streams socket.
This will cause yet another SIGIO interrupt of the server. In
this case the interrupt will be ignored because the server is
already waiting for data"
(Note: the server that this demo program refers to waits for data inside of
its SIGIO interrupt handler.)
This also seems contrary to the idea of signals being blocked or remembered.
Am I missing something? Or did I discover/re-discover something?
Raland
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: 9 Jun 94 15:28:18 From: scott@harbard.gso.saic.com (& Grier) To: comp.protocols.tcp-ip Subject: Logging anoymous FTP access
Can anyone inform me as to how we can capture and save the e-mail addresses of people who anonymously ftp on to our system? Scott scott@gso.saic.com
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: 9 Jun 1994 12:25:51 GMT From: longm@firnvx.firn.edu (Michael Long) To: comp.protocols.tcp-ip Subject: Looking for DNS for Mac and/or Windows?
I am looking for a Domain Name Server for either the Mac or windows platform. Please no suggestions for Linux or UNIX. I do not have the time for Linux and I cannot afford a UNIX box. I know there is a DNS for DOS/Windows out there, all I need is the NAME! I will do an Archie search on it. If anyone has any suggestions please e-mail me. Thanks Mike... ***************************************************************************** Michael Long - Sr. Systems Programmer Florida State University/Florida Information Resource Network/Florida D.O.E. E-mail: longm@firnvx.firn.edu Phone: (904)487-0911 *****************************************************************************
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Jun 1994 13:57:00 GMT From: manfredi@rockwell.com (Bert Manfredi, 747-6735) To: comp.org.ieee,comp.protocols.tcp-ip,comp.dcom.lans.ethernet Subject: Re: mac layer addresses
In article <Cr25Mo.EHp@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes... >In article <BILLW.94Jun7180601@glare.cisco.com> billw@glare.cisco.com (William ) writes: >>Actually, several companies, including two of the inventors of ethernet, >>seem to believe (or used to believe) that there was one MAC address per >>node, regardless of how many ports there were on that node. > >In fact, the XNS protocols demand -- or used to demand, anyway -- this >situation. This is why the original DIX Ethernet spec explicitly required >that it be possible to change the address of an Ethernet port from the >protocol software. (To understand this, it is helpful to know that XNS >folks did not have the notion of a mapping between a logical address and >a MAC address: an XNS host had one 48-bit address, period.) Pretty weird. I think that if multi-homed hosts used the same MAC physical address for each of their ports, and if they also used IP, we'd have a mess on our hands. Unless, of course, the system designers add in all the requisite firewalls. Something to ponder. Bert manfredi@rockwell.com
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: 9 Jun 1994 21:12:02 -0400 From: paulrn@aol.com (PaulRN) To: comp.protocols.tcp-ip Subject: Host volume information
I work in an environment with Macs, Unix workstations, a Vax mainframe and other stuff on Ethernet. I frequently FTP our Mac server from my Unix station and would like to know if there is a way to receive the volume info for the server. I need to know the storage space available on the Mac. The mac runs Mac TCP Connect ][ and allows the usual ftp operations, but I can't get it to give me volume info. Thanks. PRN
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: 9 Jun 1994 16:36:44 GMT From: hoehle@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) To: comp.protocols.tcp-ip Subject: security issues when adding a slip node?
Hi, We are planning to make the slip access to our modems a little bit freer than it was before. I'm wondering if there are some security issues (or holes) that are important if we allow people to start slip on our dial-in modem and thus get into our UNIX (Sun) network. Every normal user suddenly becomes root when he's on his own machine at home. Are there more security holes here than for anyone coming in through the normal Internet? Thanks for any information, Joerg Hoehle. hoehle@inf-wiss.uni-konstanz.de
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Jun 1994 17:39:17 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: What's the matter with this rips?
In article <199406090955.AA01700@bank.kemerovo.su> sova@bank.kemerovo.su writes: > Below is a core part of my current network. > > addr 193.124.197.67 193.124.197.66 > mask 255.255.255.240 255.255.255.240 > | | > ----------+-------+------+----- broadcast 193.124.197.79 > | 193.124.197.65 > mnws | 255.255.255.240 > -------+-------- > | NetWare 3.11 | LOAD TCPIP FORWARD=YES RIP=YES > | | > -------+-------- > | 193.124.196.170 > | 255.255.255.128 > ------+-------+------------------------------+------------- > | 193.124.196.131 | 193.124.196.132 > keeper | 255.255.255.128 mgw | 255.255.255.128 > -------+-------- -------+-------- > | BSDI 1.0 | routed -q | BSDI 1.1 | routed -s > | | | | > -------+-------- -------+-------- > | Taylor UUCP | 193.124.197.49 > | | 255.255.255.240 > | ------------+---------------------- > Relcom /EUnet | 193.124.197.55 > | decora | 255.255.255.240 > -------+-------- > | Ultrix 4.3 | routed -q > | | > ---------------- You've got two errors. The one which is causing your immediate problem is that you've split the network 193.124.197.x with the network 193.124.196.x. All subnets of a single network must be contiguous. Nodes not on any of the subnets view the entire network as a single entity. They do not have enough information to make a decision between the two possible routes they know about to the network, so they will often pick the wrong route. Your second error is that the network mask 255.255.255.128 is not allowed for a class C network. The subnet portion of that mask, 0.0.0.128, includes only one bit. The subnet number with all zeros and the subnet number will all ones are not allowed, so a single bit the subnet number can contain no permitted subnet numbers. You need to use a two bit mask, 0.0.0.192, in order to have two subnets. I'm not exactly sure why this hasn't caused you any problems yet. Once you clear up the first problem, I feel confident secondary problems will start to appear if you don't expand the network mask for the 193.124.196.x network. don provan donp@novell.com
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: Thu, 09 Jun 1994 20:40:08 GMT From: mark@cyantic.com (Mark T. Dornfeld) To: comp.protocols.tcp-ip Subject: Compile/link problem on DG UX
I'm not sure if this is the proper newsgroup for this posting, but hopefully some network developers live here who can help me. I am trying to compile a program supplied by QMS with their network printers that sends print data from a System V lp spooler to the printer which is set up as a TCP/IP node on the network. The linker is looking for a library (libnet.a) which does not exist on DG UX System Vr4. I do not know what functions are in libnet.a, so I don't know where else these functions might be on DG/UX. The program actually compiles and links without this library, and does not crash when run. However, all it does is spit back a list of options to me. If anyone can help with the library issues, it would be greatly appreciated. Thanks in advance. -- Mark T. Dornfeld, Cyantic Systems Corporation Voice: (416) 621-6166 1 Eva Road Suite 301 Facsimile: (416) 621-6212 Etobicoke, Ontario, M9C 4Z5 CANADA Email: mark@cyantic.com
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Jun 1994 20:56:07 GMT From: d00n@crash.cts.com (Kevin Spousta) To: comp.protocols.tcp-ip Subject: DNS Problems galore. Somebody help!
Previously I had posted a message regarding multiple hostnames 'pointing' to one IP address in the /etc/hosts file on our DNS. I received a bunch of mail regarding the 'badness' of multiple A records for one IP, some info on CNAME records and mail exchange records. I passed all of this info on to the keepers of the DNS here and they've managed to completely hose things up. Here's what I need to accomplish: I've got WP Office installed in multiple sites, all gating SMTP mail through the machine, smtpgate.sannet.gov. For political reasons, I need to 'trick' this machine into thinking it's also called cd7.sannet.gov, cd1.sannet.gov, rosecyn.sannet.gov and acctrep.sannet.gov, with more names to come. I've aliased WP Office users as user@cd7.sannet.gov, user@rosecyn.sannet.gov etc with all SMTP services being handled by the smtpgate machine. Outbound mail works like a charm and previously with the following entries in the DNS it worked great: 156.29.1.107 smtpgate.sannet.gov smtpgate 156.29.1.107 rosecyn.sannet.gov rosecyn 156.29.1.107 acctrep.sannet.gov acctrep 156.29.1.107 cd1.sannet.gov cd1 156.29.1.107 cd7.sannet.gov cd7 I need to be able to have all mail sent to the last 4 hostnames processed by themachine at 1.107 (smtpgate) This method, along with MX records in the /etc/named.data file worked, however, I was told by somebody here that multiple A records in the /etc/hosts file were not a good thing and I should use CNAME records. The keepers of the DNS are trying this and now nothing works. What's the skinny on CNAME & MX records? Can someone tell me, in straight English, how to set this up? This trial by error bit is getting old. (and unfortunately, I don't have access to make these changes so I need to tell these guys EXACTLY how to do it - Anyone want a job as a systems admin?) As usual, thanks for saving my bacon.
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: 9 Jun 1994 21:10:20 GMT From: wwds2@clark.net () To: comp.protocols.tcp-ip Subject: What is XTP?
I heard for the first time today about a protocol called XTP that is supposed to be an alternative to UDP providing guaranteed delivery. Does anyone know what XTP is, how it compares to TCP and UDP (pros+cons...) where I can get more information, supliers, etc? Thanks ------------------------ Walt Brauckmann <wwds2@clark.net> Westighouse Electric Corp.
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: 9 Jun 1994 21:42:04 GMT From: glenn@creator.ucns.uga.edu (Glenn Leavell) To: comp.protocols.tcp-ip Subject: slip-4.0 access denied problem
I'm trying to configure slip-4.0 (Rayan Zachariassen <rayan@ai.toronto.edu>)
on a Sun Sparcstation 1+ running SunOS 4.1.3. Everything seems to be working
well in the sense that the sliplogin program will configure the slip0 device
when run as superuser. However, if a normal user logs into a pseudo slip
ID (one that has sliplogin as its shell), then the message
SLIP access denied
appears, and the connection is broken. The /etc/hosts.slip file looks like
this:
slipid normal 128.192.ww.xx 128.192.yy.zz
I know that this is a vague question, but can anyone provide any pointers,
hints, suggestions, etc. as to what would cause the "access denied" error?
Thanks very much.
--
Glenn Leavell University of Georgia glenn@creator.ucns.uga.edu 706-542-3135
University Computing and Networking Services, Athens, GA 30602-1911
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 10:43:33 -0700 From: jantypas@ccnet.com (John Antypas) To: comp.protocols.tcp-ip Subject: Where to find pointers to DHCP discussions?
Subject says it all. Where can I find DHCP info. (Not to mention all of the other "next generation IP" material.
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: 9 Jun 1994 09:48:16 +0800 From: richard@iinet.com.au (Richard Keeves) To: comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.tools,comp.os.ms-windows.programmer,comp.os.ms-windows.apps,comp.os.ms-windows.apps,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip.domains,comp.unix.dos-under-unix,comp.unix.questions Subject: `Beeping' thru a Window. Help!
Hi there,
Here's the challenge...
I want to be able to alert someone in another internet location ie at
another node in another country) when i wish to talk with them
Now I know that `talk' will do that, however if the other party is in
another window (using ms windows) they will not get the `talk' alert.
So is there anything (ie any program or clever stuff) that can be done
to cause the other machine to beep ???
Or sound some other alarm??
This assumes of course that the other person is logged on...
btw I am assuming that the normal beep will not work when the other party
is not in same window as modem.
If you can understand my question, I hope you can help..
thanks... my email is
richard@iinet.com.au
Hope to hear from you if you can help
Cheers
Richard Keeves
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: Thu, 9 Jun 1994 23:46:59 GMT From: vjs@calcite.rhyolite.com (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: What is the MTU of FDDI?
In article <2t53hl$fj4@lll-winken.llnl.gov> booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes: >I'm trying to get some agreement on MTU between hosts and routers on one of >our FDDI rings, and I've realized that I don't know what the "appropriate" >MTU should be. > >My understanding is that the true MTU for FDDI is 4500 bytes. However, I >have found a recommended value of 4470 in an NSC router manual, I've seen >defaults of 4352 on both RS/6000s and Sun 4s, and have been told that 4096 >is the default for at least one router vendor. > >Clearly, 4096 would be a poor choice, as 4096 is a nice size for >allocating memory. 4136 would be better which would account for the TCP/IP >header. But since we've still got some headroom, why not bump it up so >that packets with TCP/IP options don't need to be fragmented? > >Can anyone explain why choices like 4352 or 4470 were made. Vernon, can you >tell me what SGI recommends? A popular, although not uniformly used, >Ethernet MTU is 1500 bytes. Does any such MTU exist for FDDI, or is there >really a lot of disagreement? RFC-1103,...,1188 say the MTU for IP over FDDI is 4352. ] Therefore, the MTU of FDDI networks shall be 4352 octets. This ] provides for 4096 octets of data and 256 octets of headers at the ] network layer and above. Implementations must not send packets ] larger than the MTU. 4352 was choosen in a long ago FDDI birds-of-a-feather InterOp meeting. It is less than 4500 "just in case", and more than 4096 so allow for various headers including the 100 bytes of RPC/XDR in NFS. I like to use 4096 of payload in TCP kernel code to go fast, but that's ok because since there is no law that says you must transmit full-siced frames. You need only be prepared to accept bigger frames. Vernon Schryver vjs@rhyolite.com
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 11:58:06 -0700 From: moliver@pyramid.com (Mike Oliver) To: comp.protocols.tcp-ip Subject: Re: What is the MTU of FDDI?
In article <1994Jun10.003410.15080@ns.network.com>,
Andrew Molitor <amolitor@network.com> wrote:
>In article <2t53hl$fj4@lll-winken.llnl.gov>, booloo@framsparc.ocf.llnl.gov
> (Mark Boolootian) writes:
>|> I'm trying to get some agreement on MTU between hosts and routers on one of
>|> our FDDI rings, and I've realized that I don't know what the "appropriate"
>|> MTU should be.
>|>
>|> My understanding is that the true MTU for FDDI is 4500 bytes. However, I
>|> have found a recommended value of 4470 in an NSC router manual, I've seen
>|> defaults of 4352 on both RS/6000s and Sun 4s, and have been told that 4096
>|> is the default for at least one router vendor.
>
> Not surprisingly, I'm going to say that 4470 is the right number (see
>my email address!).
Unless and until you can get an RFC issued to supersede RFC1188 the
correct answer is 4352. Above that you're in violation of the RFC and
are depending on the kindness of strange device driver developers.
Choose your own meaning of "strange".
RFC1390 is a standards track document intended to obsolete RFC1188, but
1390 makes no change to the FDDI MTU.
> The reason is that the max size of a FDDI frame is 4500,
>and if you add up the headers down to and including the SNAP header, and the
>FDDI weirdnesses and so on, you get 30 bytes of other stuff as the maximum
>size of, say, an IP datagram you can push over it.
The rationale for choosing 4352 is presented in RFC1188, which says:
The FDDI MAC specification [4] defines a maximum frame size of
9000 symbols (4500 octets) for all frame fields, including four
symbols (two octets) of preamble. This leaves roughly 4470 octets
for data after the LLC/SNAP header is taken into account.
However, in order to allow future extensions to the MAC header and
frame status fields, it is desirable to reserve additional space
for MAC overhead.
Therefore, the MTU of FDDI networks shall be 4352 octets. This
provides for 4096 octets of data and 256 octets of headers at the
network layer and above. Implementations must not send packets
larger than the MTU.
RFC1390 retains this text verbatim.
Incidentally, I imagine that the phrase "future extensions to the MAC
header" refers to source routing, which thankfully hasn't caught on for
FDDI.
> If you heave SNAP
>encapsulation, you get back a few bytes, but SNAP is a Good Thing, so don't.
Whether it's a Good Thing or not, SNAP is mandatory for IP over FDDI,
Don't leave it out if you want to talk to anyone else's implementation.
> I speculate that other vendors probably use smaller numbers for
>some sort if internal convenience.
I speculate that they'll use a smaller number than 4470 so as to be in
compliance with the RFC.
Your speculation that they might use smaller number than 4352 has been
confirmed for at least one prominent vendor by Vernon's posting -- but,
as he mentions, an implementation must still be prepared to accept
datagrams up to the full MTU size.
> Off the top of my head, I'd say the largest issue is to avoid
>fragmenting maximally sized NFS datagrams into 2 big frames, and then a
>little one extra because the first two weren't quite enough, but anything
>much over 4096 will do that for you.
I happen to agree, but oddly enough the rationale in the RFC doesn't
provide for this. MTU's for some other media do allow a little over 8K
in deference to NFS. I don't know how useful it is in practice.
> Intelligent transport protocols, like
>TCP, shouldn't really care about a few bytes one way or the other.
The protocol doesn't care. Someone striving to create an efficient
implementation very well might.
Cheers, Mike.
moliver@pyramid.com
{allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 94 00:34:10 GMT From: amolitor@blefscu.network.com (Andrew Molitor) To: comp.protocols.tcp-ip Subject: Re: What is the MTU of FDDI?
In article <2t53hl$fj4@lll-winken.llnl.gov>, booloo@framsparc.ocf.llnl.gov (Mark Boolootian) writes: |> I'm trying to get some agreement on MTU between hosts and routers on one of |> our FDDI rings, and I've realized that I don't know what the "appropriate" |> MTU should be. |> |> My understanding is that the true MTU for FDDI is 4500 bytes. However, I |> have found a recommended value of 4470 in an NSC router manual, I've seen |> defaults of 4352 on both RS/6000s and Sun 4s, and have been told that 4096 |> is the default for at least one router vendor. Not surprisingly, I'm going to say that 4470 is the right number (see my email address!). The reason is that the max size of a FDDI frame is 4500, and if you add up the headers down to and including the SNAP header, and the FDDI weirdnesses and so on, you get 30 bytes of other stuff as the maximum size of, say, an IP datagram you can push over it. If you heave SNAP encapsulation, you get back a few bytes, but SNAP is a Good Thing, so don't. I speculate that other vendors probably use smaller numbers for some sort if internal convenience. Off the top of my head, I'd say the largest issue is to avoid fragmenting maximally sized NFS datagrams into 2 big frames, and then a little one extra because the first two weren't quite enough, but anything much over 4096 will do that for you. Intelligent transport protocols, like TCP, shouldn't really care about a few bytes one way or the other. Andrew Molitor
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 01:12:00 GMT From: west@osi.ncsl.nist.gov (Jim West) To: comp.protocols.tcp-ip Subject: Re: What is XTP?
In article <2t80fs$f48@clarknet.clark.net> wwds2@clark.net () writes: >I heard for the first time today about a protocol called XTP that is >supposed to be an alternative to UDP providing guaranteed delivery. > >Does anyone know what XTP is, how it compares to TCP and UDP (pros+cons...) >where I can get more information, supliers, etc? > XTP appeared about five years ago. One of my first projects at NIST was examining XTP and comparing it to other Transport layer protocols. I haven't looked at it in four and a half years, but I'll try to tell you what I know. XTP stands for eXpress Transport Protocol. It was supposed to solve the preceived performance limitations of protocols like TCP and OSI's TP[0-4]. As I remember it incorporated both layer 3 and layer 4 (Network layer and Transport layer) functionality. XTP was designed so that it could be implemented on a chip. This was how developers proposed to get really high thoughput and low latency. A company called Protocol Engines Incorporated (PEI) was staffing up to do this five years ago. I don't remember the name of the developer of XTP but he was one of the founders of PEI (I think that they got some of their start-up money from SGI). A Dr. Alf Weaver at the University of Virginia (I think he's at UVa) was doing a lot of work with XTP. IMHO XTP got caught up in polotics. Also Van Jacobson had some interesting data that TCP could run at the levels the designs of XTP proposed. (Jacobson's research showed that TCP/IP could be optimized to have a best case path of about 300 lines of assembly code (if I remember right)). I think at one time there was an ANSI document based on XTP; I don't know how far it got. Sorry I don't have any more data but I at home right now and I threw out all my XTP notes last year (still have all my Van Jacobson papers. They are great sources of info). Jim West -- ---------------------------------------------------------------------- Speaking only for myself, not necessarily for my employer. west@mgmt3.ncsl.nist.gov
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 94 02:23:41 GMT From: cjw@nwu.edu (Christopher Wargaski) To: comp.protocols.tcp-ip Subject: Re: DNS Problems galore. Somebody help!
In <d00n.771195367@crash.cts.com> d00n@crash.cts.com (Kevin Spousta) writes:
>Outbound mail works like a charm and previously with the following entries
>in the DNS it worked great:
>156.29.1.107 smtpgate.sannet.gov smtpgate
>156.29.1.107 rosecyn.sannet.gov rosecyn
>156.29.1.107 acctrep.sannet.gov acctrep
>156.29.1.107 cd1.sannet.gov cd1
>156.29.1.107 cd7.sannet.gov cd7
>I need to be able to have all mail sent to the last 4 hostnames processed by themachine at 1.107 (smtpgate) This method, along with MX records in the
>/etc/named.data file worked, however, I was told by somebody here that
>multiple A records in the /etc/hosts file were not a good thing and I should
>use CNAME records. The keepers of the DNS are trying this and now nothing
>works. What's the skinny on CNAME & MX records? Can someone tell me,
>in straight English, how to set this up? This trial by error bit is getting
>old. (and unfortunately, I don't have access to make these changes so I need
>to tell these guys EXACTLY how to do it - Anyone want a job as a systems
>admin?)
CNAMEs are Canonical NAMEs, basically just an alias. Use a CNAME record
instead of multiple A records. Mail will not pass through a CNAME record.
MX records are for machines that do Mail eXchanging for another. For
example I want mail bound for rc-noc.acns.nwu.edu (which has an alias of
bohica.acns.nwu.edu) to be accepted by antioch.acns.nwu.edu. So I add the
records for the tables should look like this:
rc-noc.acns IN A 129.105.31.56 ; DSS, HP 9000/710
IN MX 0 antioch.acns.nwu.edu. ;
bohica.acns IN CNAME rc-noc.acns
The first line is an A record that you are familiar with.
The absence of a name in the first line means "ditto" for the name. So we
use rc-noc.acns for the name. We see that the machine that accepts mail
for rc-noc is antioch.
The third line is just an alias.
If someone sends mail to cjw@bohica.acns.nwu.edu, the machine sending the
mail (say moo.acns.nwu.edu) will resolve the name "bohica.acns.nwu.edu" and
find that the real name is "rc-noc.acns.nwu.edu". It will then also notice
that the machine "antioch.acns.nwu.edu" is the machine that is accepting
mail. So moo will resolve the IP address for antioch and send the mail
message to that machine.
Now, the sendmail.cf for antioch has to have a rule added so that it will
accept mail for the machine called rc-noc. If you would like info on that,
let me know.
Good luck!
cjw
--
Christopher Wargaski cjw@nwu.edu Technical Services Supervisor
Northwestern University Network Operations Center 708-467-NNOC
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 11:31:42 -0500 From: dawkins@bnr.ca (Spencer Dawkins) To: comp.protocols.tcp-ip Subject: Stop me before I kill again (TCP vs UDP)
We have "a product" that runs over proprietary link-layer-and-up protocols, that we also want to use over "corporate lans". I've been asked my opinion on a few points, and I've given them, but if I'm giving horrible advice, I'd appreciate hearing alternative viewpoints. The deal: all applications use a proprietary link-layer protocol (call it PLL, for convenience). A unix process MUXes all applications on a physical point-to-point connection. The interface between the application and the MUX software is connectionless. The development group plans to keep the same interface between the applications and the MUX layer, and to rewrite the MUX layer to use TCP or UDP. Other stuff: Most application-to-application conversations will be over Ethernet, but some conversations will take place over WAN connections. What I said: "If you're going to keep the same application-level interface, which is connectionless, you might as well use UDP." Why I said it: The applications already run timers and sequence numbers, because of the connectionless interface to the MUX software. The developers planned to MUX all conversations over a single TCP connection, if they used TCP. I was concerned about applications which sent large numbers of packets back-to-back causing other applications sending relatively time-critical "query/response" exchanges to be flow controlled. The developers planned to use the FTP application (over TCP, obviously) to move several types of large files between nodes. much of the need for TCP-level flow control was already being diverted to FTP, which uses TCP anyway. The classic "large number of clients per service" scenerio applies. I did not want to support, potentially, hundreds of clients using TCP for (most often) application-level datagram exchanges anyway. Caveats I've already said: The applications really _do_ have to run their own timers and sequence numbers. (If they don't, it's a problem on the PLL product anyway, so they have to anyway). If an application is sending large numbers of messages "back- to-back", it needs to be at least minimally aware of congestion, and slow itself down until congestion clears. We may not need all of Van Jacobson's code, but we do need to back off more aggressively than we probe for bandwidth. Applications with this characteristic will probably be able to be replaced by ftp _in our product_ (this is not a general assertion). What I know to worry about: Most corporate firewalls allow relatively little in the way of UDP traffic (heck, most allow relatively little in the way of TCP traffic). Is what I'm suggesting dead out-of-the-box? I don't know everything. What else should I investigate to make sure I don't give the developers bad advice that _everyone_ knows is bad advice? (I sure don't mind encountering _new_ problems -- I just hate _"used"_ problems.) If you phrase your favorite concern in the form of a question pregnant with meaning, such as "ummm, how will that work when you have a customer who refuses to pass _any_ UDP traffic?", that's everything I can hope for from this posting. If you phrase it as "What I'd do in that case is use Transport-Independent RPC" or some other miracle cure, that would be fantastic, but it's not required -- just the heads-up is appreciated. Spencer -- - Spencer Dawkins Internet: dawkins@bnr.ca (214) 684-4827 - - A flashing "12:00" on the VCR of life. -
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 03:23:21 GMT From: iddasl@iddis.com (Alan Siping Liu) To: comp.protocols.tcp-ip Subject: message lost in UDP socket
Hi everyone, We are using UDP socket to transfer data across hosts. We find that messsage get lost when the sending speed is increased. The problem is that the speed at which we start lossing message is quite low -- about 500 messages per second, each contains about only 40 bytes. The receiving process doesn't have heavy processing on the received data. The testing is conducted on a coupe of Sparc10's on a rather quiet, isolated Ether net. A related question is: when using BSD sockets, is there any way to increase the buffer beyond 64K? In the testing described above, netstat reported IP message loss at the receiver side. Can I conclude that the message loss is due to the limited socket buffer? Or maybe the OS is not configured properly? Thanks i advance. Alan Liu.
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 10:48:06 -0400 From: hzhou@cs.utk.edu (Honbo Zhou) To: comp.protocols.tcp-ip Subject: UDP flow control and retransmission?
I would like to know if there is a book about EFFICIENT (preferably with source codes) flow control and retransmission over UDP socket? Thanks.hb
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 08:57:48 EDT From: rbecker@sup.xyplex.com (Ralph Becker) To: comp.protocols.ppp,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Questions regarding SLIP/PPP terminal server setups
In article <CqqE1u.4Jq@oucsace.cs.ohiou.edu> rbarrett@oucsace.cs.ohiou.edu (Rich Barrette) writes: >I have been involved in a project setting up a SLIP/PPP terminal >server and offering these services to Windows and Mac users >throughout campus. Right now we have a small exerimental group >running smoothly. [snip] >The other pressing question was one of usage. How do we monitor >usage and decide who is doing real work? i.e. It would be highly >undesireable for someone to be logged into the server all of the >time while other people could do work. How do we monitor and decide >who is doing what? The subject can get complicated because we want >to offer this to students, some of which are CS and Engineering types >who can beat most simple monitoring systems by sending pings every >once in a while or use even more elaborate mechanisms. The Xyplex server is not really going to provide you much in the way of traffic analysis. About all you can do is set up inactivity timeouts that will logout the port if there is no activity on it for some time. As you said, this is easily defeated. You can do IP address security, however. This will let you restrict where users can connect to. If, for example, you wanted to limit users to your local subnet only, this is easy to do. Ralph Becker Xyplex Customer Support [Tech. Support hotline 800-435-7997] rbecker@sup.xyplex.com or 71174.1262@compuserve.com
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 94 07:22:57 GMT From: tom@wcc.oz.au (Tom Evans) To: comp.protocols.tcp-ip Subject: ICMP Redirect THEN Host Unreachable?
I've got a packet trace here that looks WEIRD to me. There's two
famous-name IP routers on a backbone with a host, call them R1, R2 and
H1. There's another host on the other side of R2:
[ R1 ]============[ R2 ]======[ H2 ]
||
[ H1 ]
H1 sends a packet (an ICMP Ping reply) to H2, but via R1 (its default gateway).
R1 forwards the packet via R2 to H2, and sends an ICMP Redirect to H1. Fine.
Then R1 sends an ICMP Host Unreachable to H1 for the same packet. Not fine.
This doesn't seem to be what the RFC says. Any opinions? Is this
legal? Is R1 busted?
If this is judged to be "illegal" I'll post details when I get model
numbers and more complete packet-dumps and so on
========================
Tom Evans tom@wcc.oz.au
Webster Computer Corp P/L, 11 Glenvale Crescent Mulgrave, Melbourne 3170
Victoria, Australia 61-3-561-9999 FAX ...560-0067 A.C.N. 004 818 455
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 14:31:54 -0400 From: danglert@source.asset.com (Terry Dangler) To: comp.protocols.tcp-ip,comp.unix.aix Subject: IP Adressing of Multiple Interfaces
Hi We are using an RS/6000, is there any reason why the following IP addressing scheme would not work: Ethernet Interface IP Address: 192.131.125.10 connects to gateway and Internet SLIP Interface IP Address: 192.131.125.25 attached to Xstation Token Ring Interface IP Address: 192.131.125.33 connects to LAN currently: Ethernet Interface IP Address: 192.131.125.10 Token Ring Interface is 192.132.104.33 Please respond directly: TIA
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 08:41:24 GMT From: gta@server1.ewi.ch (Gerster) To: comp.protocols.tcp-ip Subject: telnet/ftp with American Online
Dear Members, I' have a question about American Online. I hope I'm in the right group. It is possible for an American Online User to make telnet or ftp connection to hosts on the INTERNET ?. In case of yes, what the user should do. Andreas ---------------------------------------------------------------------------- Andreas Gerster | phone: +41 (0)1-385 21 86 (direct) Electrowatt Engineering Services, Ltd. | +41 (0)1-385 33 22 (main) Bellerivestrasse 36, P.O. Box | fax: +41 (0)1-385 24 25 CH-8034 Zurich | e-mail: gta@ewi.ch Switzerland | X400 : O=EWI/p=EUNET/a=ARCOM/c=CH ----------------------------------------------------------------------------
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 09:15:08 GMT From: hjb@netcom.com (squeedy) To: comp.protocols.tcp-ip Subject: Re: What is XTP?
Jim West (west@osi.ncsl.nist.gov) wrote: : A company called Protocol Engines Incorporated (PEI) was staffing up to do : this five years ago. I don't remember the name of the developer : of XTP but he was one of the founders of PEI (I think that they : got some of their start-up money from SGI). trivia: PEI is no longer, they closed the shop a couple of years ago. it was founded by Greg Chesson (UUCP-g protocol, Datakit protocol engine), who was and still is at SGI as a chief scientist. Greg, the PEI/XTP TAB members and engineers at PEI designed the protocol. PEI actually finished the first chipset that could do a subset of TCP/IP (with some provisions for XNS and XTP), but the design never went to production. a lot of us who worked at PEI are now working at different places now, some are consultants, many are working at SGI and Hybrid Networks, Inc. the XTP itself has been taken over by XTP consortium, a left-over from PEI. -- hwajin PEACEFUL STAR
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 16:42:35 From: MSNIDER@rapnet.sanders.lockheed.com (Marc Snider) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.os.msdos.apps Subject: BOOTP server for PC ?
Does anyone out there know of a BOOTP server implementation which will run under either DOS or Windows? Thanks in advance, Marc Snider msnider@rapnet.sanders.lockheed.com Marc Snider msnider@rapnet.sanders.lockheed.com
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 13:36:19 GMT From: goeritz@conware.de (Huergen Goeritz) To: comp.protocols.tcp-ip Subject: HELP: IP(ARP) over Token Ring
Hi, we are a company which develops Bridges/Routers. We support Ethernet/FDDI/Token Ring/ISDN/WAN-Interfaces. Right now I am dealing with Token Ring and there I encountered a problem. In an IP-environment, ARP is used to translate Internet addresses to Token Ring addresses when needed. The ARP protocol has several fields that parameterize its use in any specific context. One of these fields is the Hardware Type Code hrd - 16-bits. The hardware type code assigned for IEEE 802 networks (Token Ring, FDDI ...) is 6. The hardware type code assigned for Ethernet networks is 1. Unfortunaltely, differing values between Ethernet and IEEE 802 networks cause interoperability problems in bridged environments. In order to not preclude interoperability with Ethernets in a bridged environment, ARP packets shall be transmitted with a hardware type code of 1. ARP packets shall be accepted if received with a hardware type code of 1. In order to not preclude interoperability in a bridged environment, the hardware addresses in ARP packets must be carried in 'canonical' bit order, with the Group bit positioned as the low order bit of the first octet. As Token Ring (and FDDI) addresses are normally expressed with the Group bit in the high order bit position, the addresses must be bit-reversed within each octet. This is true for FDDI (see RFC 1390), but do you know something about Token Ring how I save to deal with ARP and the MAC-address representation. How do you solve the problem in a bridged environment? Do you have a solution or can you help me in some way. Thank you Juergen Goeritz e-mail : goeritz@conware.de
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 18:38:25 UNDEFINED From: treynold@fred.lasalle.edu (Tommi) To: comp.protocols.tcp-ip Subject: Bootp: Across routers/Segments/Etc. ?
Hi all, I've recently been fiddling with using bootp to try and dish out IP's for a small subnet which will eventually contain some slip and ppp access points. My problem is this: The segment I am setting up will be the 13 segment (xxx.xxx.13.xxx), which will be connected via router to the 10 segment. On the 10 segment rest several of our un*x machines, including the linux box which plans on running bootpd. I don't want to move the linux box to the 13 segment. Isn't bootp supposed to travel over routers, much like rarp would not? I thought that I remembered reading this a while ago (has been a while though...), but monitoring the traffic on the new 13 segment as I tried to get a request across to the 10 showed several broadcast udp packets at fixed intervals from the client. Now, certainly realizing that a router should not in any case forward a broadcast packet, is there any way to get bootp across a router??? (the routers are, currently, running md-dosip routed (yes, I know, get a real router :) Also, will bootp allow for me to eventually distribute ip's from a certain sort of "available ip" pool rather than by ethernet address, so that I can accomodate ppp ??? Any help appreciated! --- Tommi treynold@fred.lasalle.edu The above are my thoughts; if you don't like them, don't read them!
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 13:40:55 GMT From: bob@astph (Bob Ford) To: comp.protocols.tcp-ip Subject: Broken rwho & ruptime on ISC
We are running ISC v. 3.0 on one system, and ISC v. 4.0 on another. They are connected via a bridge running on a 56K leased line. From the 3.0 to the 4.0 machine, ruptime and rwho work correctly, showing who is on both remote and local systems. Going the other way, from 4.0 to 3.0, neither ruptime or rwho works, reporting no users on the systems, and machines down that are in reality up. Thinking that /etc/rwhod was broken, I tried using the 3.0 rwhod on the 4.0 system, but it didn't help. I also tried the reverse (4.0 rwhod on 3.0 system), and no joy. I should also mention that ruptime and rwho work fine on the 4.0 machine for locally connected systems; the problem is over the 56K line. In fact, on one of the locally connected machines, we are also running v. 3.0, so it probably isn't a 4.0 to 3.0 incompatability. Any help or pointers on what we are doing wrong would be much appreciated. -- Bob Ford Voice:(814)234-8592 x36 INTERNET: astph!bob@cse.psu.edu FAX: (814)234-1269 Philadelphia Phillies - 1993 National League Champions
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 14:57:31 GMT From: d00n@crash.cts.com (Kevin Spousta) To: comp.protocols.tcp-ip Subject: Re: Connecting the PC to the Internet
In <Zi9PX0j.bankrupt@delphi.com> Peter Chapman <bankrupt@delphi.com> writes: >Okay . . . here goes. Can someone direct me to a source for connecting my >lonesome extra 386 machine to the Internet so that other people can FTP >or TELNET to my machine to retrieve certain law-related information at no >charge. I'd love to put some information out on the Information Highway >for others to see and use, but I can't figure out where to begin. A book >entitled "How to connect a PC to the Internet over the phone lines in 100 >easy steps" would be really convenient. Any ideas? Certainly.. Call your local Internet service provider and get yourself a SLIP account. Tyupically, you'll be able to download some SLIP software from the provider's machine and the rest of the TCP/IP suite can be had by rummaging around the 'net. (Try ftp'ing to zaphod.ncsa.uiuc.edu) About a year ago I did the same thing. I'm now using commercial products (since I have some money - finally) but I did it for about 8 months with the free stuff. If ya have any questions, blast me some E-mail and I'll try and help ya out.
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 15:54:02 GMT From: kangs@minerva.cis.yale.edu (Sung Moon Kang BK94) To: comp.protocols.tcp-ip Subject: Appletalk through tcp-ip
Hi, I don't usually read this newsgroup, but this topic came up during a
conversation and this seems like a good group to ask....
I know that in theory it is possible to tunnel Appletalk through tcp-ip,
so theoretically it should be possible to create a wide area *appletalk*
network from say... Yale to Stanford through the internet. So it should
be possible to say... access an Appletalk fileshare server in Stanford
from a Mac at Yale... in theory.
Beside the fact it would be really really really slow...
Is there an application/extension/whatever that actually does this?
Please email to kangs@minerva.cis.yale.edu as I don't regularly read
this newsgroup. Thanx very much.
--
---------------------------------------------------------------------------
Sung Moon Kang BK 94 | "You don't belong in this century
kangs@minerva.cis.yale.edu | do you, Sung?"
| - Richard Cho 5/30/94
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 16:05:48 GMT From: underlan@jumbo.Read.TASC.COM (Samuel L/ Underland) To: comp.protocols.tcp-ip Subject: Subnetting with multiple nets
Hello,
I have a question about OSPF and subnetting with two different Class C
addresses. I have a configuration, pictured below, with a central hub
router and numerous remote sites. I want to subnet but don't have enough
subnets (allowing for expansion) within the range for one Class C address.
OSPF doesn't permit routing from a subnet in one network through a different
network, to a subnet of the originating network. I would like to divide the
available address space approximately evenly among the sites.
Questions:
1) When I route through a Hub system (AGS+ in this case), which network
is it considered part of? A, B, or Both?
2) Will the Hub router route from all combinations of A and B? Does it
matter what the LAN is at the Hub site?
3) Is making this work vendor or software rev dependent?
Configuration:
central site LAN (subnet A.A.A.n)
----------------
|
----------------
| Hub Router |
---------------- Remote LANs
| | | | | |
| | | | | --A.A.A subnet1
| | | | ----A.A.A subnet2
| | | ------A.A.A subnetn-1
| | --------B.B.B subnet1
| ----------B.B.B subnet2
------------B.B.B subnetn
Many thanks,
Sam Underland
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 16:18:18 GMT From: tudball@lis.pitt.edu (A. Bruce McDonald) To: comp.protocols.tcp-ip.domains,comp.protocols.tcp-ip,comp.protocols.ppp Subject: Re: routing on a router/gateway
Sanjeev Shah (shah@abba) wrote: : I have a class C address and use a UnixWare host (SVR4.2) to connect : to the internet via a dialout PPP link. The machine has two interfaces : (wd0 and ppp) and IPFORWARDING is set to 1. I am using separate IP : addresses for the two interfaces. : When I rlogin to a host on the internet, I see that I have come over the : ppp0 interface's IP. i.e. 'who' on a SunOS host shows my userid and the : IP address of ppp0 (199.xxx.xxx.3). I had really like to see this as : the IP associated with wd0 (199.xxx.xxx.2). i.e. I want the unix box : to act as a router and just pass the IP packets via the ppp0 interface. : i.e. icon->icon2->provider->internethost. Is this possible using routed? : This scenario should be true of any router (cisco, etc.) in a big : organization. I am sure their router passes the IP of the originating host : and not its own IP as the originator IP or is my case special because of PPP? Are you doing your rlogin from the SVR4 machine? i.e. are you telneted to that machine, or are you on another machine and using the Unixware box purely as a router? If you are using it just as a router, then you should be seeing what you want, however if your logged onto it, then the ppp0 interface is the source interface of your packets. This is as it should be according to the IP routes. I do not know if there is someway to play around with routing internally to use another interface as your IP source interface... --Bruce -- ------------------------------------------------------------------------------- A. Bruce McDonald tudball@icarus.lis.pitt.edu University of Pittsburgh "All Good Things..." Work Phone: (412) 624-9499 Home Phone: (412) 731-0767 -------------------------------------------------------------------------------
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 16:21:52 GMT From: tudball@lis.pitt.edu (A. Bruce McDonald) To: comp.protocols.tcp-ip Subject: Re: What is XTP?
wwds2@clark.net wrote: : I heard for the first time today about a protocol called XTP that is : supposed to be an alternative to UDP providing guaranteed delivery. : Does anyone know what XTP is, how it compares to TCP and UDP (pros+cons...) : where I can get more information, supliers, etc? : Thanks : ------------------------ : Walt Brauckmann <wwds2@clark.net> : Westighouse Electric Corp. There are a number of articles and a book. Eamil me if you would like references. --Bruce -- ------------------------------------------------------------------------------- A. Bruce McDonald tudball@icarus.lis.pitt.edu University of Pittsburgh "All Good Things..." Work Phone: (412) 624-9499 Home Phone: (412) 731-0767 -------------------------------------------------------------------------------
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 16:23:47 GMT From: tudball@lis.pitt.edu (A. Bruce McDonald) To: comp.protocols.tcp-ip Subject: Re: UDP flow control and retransmission?
Honbo Zhou (hzhou@cs.utk.edu) wrote: : I would like to know if there is a book about EFFICIENT (preferably with : source codes) flow control and retransmission over UDP socket? Thanks.hb Why don't you use TCP? Efficient flow control and retran have the topic of a great deal of research in this areana. --Bruce -- ------------------------------------------------------------------------------- A. Bruce McDonald tudball@icarus.lis.pitt.edu University of Pittsburgh "All Good Things..." Work Phone: (412) 624-9499 Home Phone: (412) 731-0767 -------------------------------------------------------------------------------
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 16:44:24 GMT From: shah@abba.fcmc.com (Sanjeev Shah) To: comp.protocols.tcp-ip Subject: routing on a router/gateway
I have a class C address and use a UnixWare host (SVR4.2) to connect
to the internet via a dialout PPP link. The machine has two interfaces
(wd0 and ppp) and IPFORWARDING is set to 1. I am using separate IP
addresses for the two interfaces.
When I rlogin to a host on the internet, I see that I have come over the
ppp0 interface's IP. i.e. 'who' on a SunOS host shows my userid and the
IP address of ppp0 (199.xxx.xxx.3). I had really like to see this as
the IP associated with wd0 (199.xxx.xxx.2). i.e. I want the unix box
to act as a router and just pass the IP packets via the ppp0 interface.
i.e. icon->icon2->provider->internethost. Is this possible using routed?
This scenario should be true of any router (cisco, etc.) in a big
organization. I am sure their router passes the IP of the originating host
and not its own IP as the originator IP or is my case special because of PPP?
I have also tried subnetting with the same results. For subnetting
I used 199.xxx.xxx.33 for ppp0 and 199.xxx.xxx.65 for wd0 and a
netmask of 199.xxx.xxx.224. Any help is appreciated.
+----------+ [icon2] [provider] +----------+
| | ppp0 (199.xxx.xxx.3) (164.xx.xx.xx) | |
| unixware |------------------------------------------| internet | internet
| host | | provider |-------->
| | wd0 (199.xxx.xxx.2) | |
| |------+ [icon] | |
+----------+ | +----------+
|
[iconnet]
199.xxx.xxx.0
|
(planned LAN)
netstat -r
----------
Routing tables
Destination Gateway Flags Refs Use Interface
localhost localhost UH 0 0 lo0
provider icon2 UH 0 0 ppp0
default provider UG 1 1276 ppp0
iconnet icon U 0 0 wd0
--
Sanjeev Shah internet: shah@abba.fcmc.com
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 17:41:33 GMT From: venki@actel.com (venki muthanna) To: comp.protocols.tcp-ip Subject: Redirection of stdout and stderr to a socket.
Hi, I would like to know the easy way out to redirect stdout and stderr to sockets. I need this to work on a PC platform. I am using PCTCP from FTP Software. Thank you, Venki. venki@actel.com
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 18:05:41 GMT From: mfagan@dude.watson.ibm.com (Michael Fagan) To: comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.tools,comp.os.ms-windows.programmer,comp.os.ms-windows.apps,comp.os.ms-windows.apps,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip.domains,comp.unix.dos-under-unix,comp.unix.questions Subject: Re: `Beeping' thru a Window. Help!
> I want to be able to alert someone in another internet location ie at > another node in another country) when i wish to talk with them > <rest deleted> How about zephyr? In fact, you can forget about talk altogether and use zephyr. I must confess, though, I am not sure if zephyr has been ported to the Dos/Windows world. Cheers, Mike -- ------------------------------------------------------------------------- Michael S. Fagan | IBM Research mfagan@watson.ibm.com | http://www.watson.ibm.com/homes/mfagan/home.html -------------------------------------------------------------------------
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 18:10:25 GMT From: netcom@nbnet.nb.ca (Atlantic Netcom Inc) To: comp.protocols.tcp-ip Subject: FAQ?
Could some kind soul point me to the FAQ? I can't find it posted in comp/news.answers or anywhere else. Tks a 10E6 Rod
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 20:11:35 GMT From: jprado@lauca.usach.cl (Jorge Andres Prado Troncoso) To: comp.protocols.tcp-ip Subject: NIS <----> PCNFS problem !
Hello...
We are running PCNFS 5.0 under Ultrix 4.3 (DEC System 5000/240)
and yellow page (yp).
All works fine, but in Windows 3.1, pc-nfs' network services
(telnetw, ftpw and others) only use the NIS map (Hostmap) and doesn't
resolve in the name server host.
What shall I do to correct this problem?, i.e., pc-nfs' services
under Windows work with the name server host.
Thanks in advance....
Jorge Prado T.
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 20:13:00 GMT From: meadogc@poup1.dnet.dupont.com (Greg C. Meador) To: comp.protocols.tcp-ip Subject: TCP/IP Protocol Stack for Macintosh Comp?
I am looking for a freeware or shareware TCP/IP protocol stack to use with Macintosh computers? We are trying to establish a FreeNet and we are wondering what is available. If possible can you please provide the site and directory path. If not just a file name will do. Thanks, Greg C. Meador meadogc@poup1.dnet.dupont.com
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 1994 20:17:14 GMT From: shair@uiuc.edu (Bob Shair) To: comp.protocols.tcp-ip,comp.unix.aix Subject: Re: IP Adressing of Multiple Interfaces
danglert@source.asset.com (Terry Dangler) writes: >We are using an RS/6000, is there any reason why the following IP >addressing scheme would not work: > >Ethernet Interface IP Address: 192.131.125.10 connects to gateway and Internet >SLIP Interface IP Address: 192.131.125.25 attached to Xstation >Token Ring Interface IP Address: 192.131.125.33 connects to LAN Yup, almost certainly won't work. You don't state what your netmask is, but it's likely 255.255.255.0 . This means that the first three octets are used to address the network, and the last octet the device (adapter) on the network. You have place your Ethernet, Token Ring, and SLIP interfaces all on the same physical network. They'll have to be: 192.131.125.10 Ethernet ... connects to outsied world, must be an assigned address. Something else for the other two. e.g. 192.131,100.1 Ask yourself what the 3-octet network addresses will be. Unfortunately, this means that the workstations on the Token Ring and SLIP won't be visible to/from the Internet. This could be fixed with: More assigned class C networks (Good luck!), Subnetmasking further... e.g 255.255.255.240, which would allow up to 14 addresses on your token ring, or Proxy ARP, which I believe is not available on AIX. -- Bob Shair shair@uiuc.edu Open Systems Specialist SHAIR@UIUCVMD (bitnet) Champaign, Illinois 217/356-2684
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 20:27:15 GMT From: LJ13285@LMSC5.IS.LMSC.LOCKHEED.COM To: comp.protocols.tcp-ip Subject: Mac requesting a RPC to Unix
Does anyone know how to execute a process on a Unix machine with the request be ing initiated by a Macintosh. The Macintosh should send a message/request over the network to a Unix machine. After the Unix machine receives the request, it will process the request and send back the results. I think this requires a RPC protocol but I haven't found one for the Macintosh. Also, does anyone know how to access MAC/TCP or know if there is a socket program on the Macintosh to access TCP/IP. Thanks.
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 20:36:41 GMT From: LJ13285@LMSC5.IS.LMSC.LOCKHEED.COM To: comp.protocols.tcp-ip Subject: How do you program MAC/TCP?
How do you program TCP/IP calls on a Macintosh. Are there any sockets that you can use? Or do you know how to interface with MAC/TCP. Please let me know. Thanks.
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 20:41:09 GMT From: LJ13285@LMSC5.IS.LMSC.LOCKHEED.COM To: comp.protocols.tcp-ip Subject: Sockets for the MAC?
Is there a Socket program for the Macintosh to access TCP/IP?
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: 10 Jun 94 21:00:57 GMT From: mjg@cs.stanford.edu (Michael J Graven) To: comp.protocols.tcp-ip Subject: Re: DNS Problems galore. Somebody help!
With a nod to Chris, may I present my own interpretation of the
questions, and perhaps a few answers.
I will approach the issue purely from a DNS/BIND standpoint. If you've
got more than just the canonical hostname and localhost in your
/etc/hosts, I'll disclaim responsibility. Never was that responsible,
anyway.
d00n@crash.cts.com (Kevin Spousta) writes:
> I've got WP Office installed in multiple sites, all gating SMTP mail through
> the machine, smtpgate.sannet.gov. For political reasons, I need to 'trick'
> this machine into thinking it's also called cd7.sannet.gov, cd1.sannet.gov,
> rosecyn.sannet.gov and acctrep.sannet.gov, with more names to come. I've
> aliased WP Office users as user@cd7.sannet.gov, user@rosecyn.sannet.gov etc
> with all SMTP services being handled by the smtpgate machine.
Interpretation: you have a machine whose true name (as returned by
hostname, for example) is smtpgate. (I'll leave off the suffix for
brevity.) This machine needs also to be able to receive mail addressed
to users at machines named cd7, rosecyn, et alia.
> Outbound mail works like a charm and previously with the following entries
> in the DNS it worked great:
>
> 156.29.1.107 smtpgate.sannet.gov smtpgate
> 156.29.1.107 rosecyn.sannet.gov rosecyn
> 156.29.1.107 acctrep.sannet.gov acctrep
> 156.29.1.107 cd1.sannet.gov cd1
> 156.29.1.107 cd7.sannet.gov cd7
Now, hold on a minute. That looks a lot like a hosts file, not a DNS
database. First step: get rid of the duplicate entries in your hosts file
excepting the one for the canonical name, smtpgate.
> I need to be able to have all mail sent to the last 4 hostnames processed
> by themachine at 1.107 (smtpgate)
In other words, you want all the mail intended for hosts cd1, cd7,
acctrep, and rosecyn to be processed through the host smtpgate.
> I was told by somebody here that
> multiple A records in the /etc/hosts file were not a good thing and I should
> use CNAME records.
Depends on what you want to do; it's not a unilaterally "bad" thing and
does have its uses.
> What's the skinny on CNAME & MX records?
Briefly (very briefly), if a CNAME record for a host X points to a
host Y, then the To: address of the mail is rewritten from "user@X" to
"user@Y". A connection is opened to host Y, and the mail is delivered
as though X never were in the picture at all. A CNAME resource record is
like a pointer that's automatically dereferenced before any delivery is
attempted.
If host X has an MX record that points to host Y, then the mail is not
rewritten at all. Sendmail opens a connection to host Y and says,
"Here's mail for user@X. Can you take care of it?"
If host X has neither a CNAME nor an MX record, then its A record is
consulted and a connection opened. Some will contend this behavior is
pathological. I'll offer no opinion.
It sounds like what you want to do is use MX records. This way, hosts
on the outside will first try to deliver to smtpgate, and you'll still
be able to have a unique A record for each of the other servers.
In order to do that, you'll need to make some configuration decisions in
the mailer software on smtpgate. If you're running Sendmail, you can
set a class (class w on older Sun sendmail.cf's) with the names of
machines on whose behalf smtpgate should accept mail. Then, you can
add rules in the machine-dependent parts of sendmail's rulesets to allow
receiving (and redelivering) mail for these aliases. A discussion of
that is far, far beyond the scope of domains. I suggest
Costales/Rickert/Allman's {Sendmail}, published by O'Reilly and
Associates, in lovely (hot) Sebastopol, CA.
If you're not running Sendmail on smtpgate, well ... you'll have to
peruse your mail delivery software manuals to see how to relay mail.
--
-Michael "Jealous gun-toting ex ends a cozy weekend"
mjg@cs.stanford.edu --Headline, {Chicago Tribune}, 5 Jan 92
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 21:06:52 GMT From: rstevens@noao.edu (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: message lost in UDP socket
> We are using UDP socket to transfer data across hosts. We find > that messsage get lost when the sending speed is increased. The > problem is that the speed at which we start lossing message is > quite low -- about 500 messages per second, each contains > about only 40 bytes. The receiving process doesn't have heavy > processing on the received data. The testing is conducted on > a coupe of Sparc10's on a rather quiet, isolated Ether net. Welcome to the world of unreliable, connectionless protocols. > A related question is: when using BSD sockets, is there any > way to increase the buffer beyond 64K? In the testing described above, > netstat reported IP message loss at the receiver side. Can I > conclude that the message loss is due to the limited socket buffer? > Or maybe the OS is not configured properly? Assuming you are checking the return value of sendto(), realize that there are *few* causes for it to return an error. Assuming your system has a route to the destination, that the kernel has enough mbufs, and that the selected interface has room on its send queue, sendto() returns OK. The size of the UDP send buffer really doesn't matter, since nothing is queued at the UDP layer. UDP takes your data, plots on a UDP header, calls ip_output(), who queues the IP datagram on the interface send queue. Most interfaces have a send queue limit of 50 and I think you need kernel sources to change this. So, if sendto() is returning OK, the datagrams are being dropped either by an intermediate router or by the destination. The size of the socket receive buffer on the destination *does* indeed matter, as this could be where they're being lost. Run "netstat -s" before and after, in the receiver, and check the UDP socket overflows to see if this is the problem. Increasing SO_RCVBUF by the application will help this. There was a thread on some newsgroup recently where someone claimed that UDP was "faster" than TCP. That's false in most situations, since you lose all flow control as you're finding out. A good, well-tuned implementation of TCP should be able to beat any naive UDP application. And if you take your naive UDP application and start putting in all the features from TCP (slow start, sliding window, acknowledgments, ...) you're reinventing the wheel. Rich Stevens
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 94 22:44:40 GMT From: valenzue@mmpc.ssd.lmsc.lockheed.com (C. Valenzuela) To: comp.protocols.tcp-ip Subject: TEST
Test
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 1994 23:03:37 GMT From: davido@flagstaff.Princeton.EDU (David Lawrence Oppenheimer) To: comp.unix.admin,comp.unix.misc,comp.unix.questions,comp.sys.sun.admin,comp.sys.sun.apps,comp.sys.sun.misc,comp.protocols.tcp-ip Subject: SUMMARY: Need cslip help!
Thanks to those who responded to my problem with CSLIP on a Sun SS5 running SunOS 4.1.3_U1. My question was: ---------- Forwarded message ---------- I am having a very difficult time trying to get cslip to work on my Sun SS5. (I am using the version currently on the math.berkeley.edu FTP site.) Pertinent information: I am using a Sun SS5 with SunOS 4.1.3_U1. I am using a Hayes modem but am having no trouble communicating with the modem (i.e. regular tip dialout works). I do not have Ethernet connected to my system, just the modem through Serial Port A. I have created /dev/cua0 as specified in the cslip instructions. I have installed the cslip loadable kernel module for sun4m. I have modified the cslip login script to suit the SLIP terminal server I dial into. My problem: I run on_all_times as root (after modifying the /etc/remote, /etc/phones, slip.hosts, slip.login, and slip.logout files appropriately for my site) and get "login failed: exit status 2 from /etc/slip.login" Then I decided to try the commands by hand. First I did ifconfig sl0 my_ip_address terminal_server_ip_address netmask correct_netmask but I get ifconfig: ioctl (SIOCSIFADDR): Invalid argument [more material was here, but deleted] The problem seems to be that I had hacked the slip.login script to bits, without understanding well enough what was going on in it. In the process of investigating this problem, I discovered that I was using an outdated version of cslip (2.6 instead of 2.7). So I took cslip 2.7 from ee.lbl.gov and was pleasantly surprised that it came with excellent documentation, unlike the 2.6 docs which was sparse and had typos (only the specific version I took; this comment does not necessarily apply to all versions of 2.6 on the net.). I followed the 2.7 instructions, didn't hack any files, and it worked on the first try. Thanks to those who responded. David Oppenheimer davido@phoenix.Princeton.EDU
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: Sat, 11 Jun 1994 02:48:39 GMT From: nigel@coles.com.au (Nigel Harwood) To: comp.protocols.tcp-ip,comp.sys.ncr Subject: How to tear down a TCP over X.25 connection?
Folks, I have a System 3000/3450 AT&T box running Unix SVR4 and Win-TCP/IP. This box talks to 400 other 3450 boxes over an X.25 private network. I use Win-TCP/IP over X.25 to do RPC calls from the 400 boxes to the one box. The work being done is very quick <4 secs per connection. The 400 systems call time is hashed over an, that is all the systems are distributed more or less evenly over a 60 minute window. They may also however be trying to call in different hours due to their own processing constraints. The problem is that the host box has only 32 svcs and TCP/IP has a minimum timeout of 1 minute. This means that one a system connects and does its RPC stuff the 2 SVCs it used remain after it has finished for a further 56 seconds. This leads to a total choke up of the 32 svcs. Questions: 1/ Is there a way for the host/remote end to tear down the connection after completion? 2/ Is there a way to cause the TCP/IP timeout to be something more reasonable for my circumstances such as 10 seconds. Any help appreciated. Regards -- <<<<<<<<<<<<<<<<<<<<<<<<<<< Nigel Harwood >>>>>>>>>>>>>>>>>>>>>>>>>> << Post: Coles Supermarkets, PO Box 480, Glen Iris 3146, Australia >> << Phone: +61 3 829 6090 E-mail: nigel@coles.com.au >> << FAX: +61 3 829 6886 >> -- The opinions of the poster do not necessarily represent those of the company.
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: Fri, 10 Jun 94 15:26:46 +0800 From: Mark Dignam <digger@omenii.omen.it.com.au> To: comp.protocols.tcp-ip Subject: LWP TCP/IP API calls - Docs anywhere?
I am trying to set up some TCP/IP connectivity on my system here, and require the specs for the Lan Workplace API. Any ideas on where to start looking? Mark... digger@omen.it.com.au
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: 11 Jun 1994 08:11:18 GMT From: bq274@cleveland.Freenet.Edu (Andy J. Berkvam) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.os.msdos.apps Subject: Re: BOOTP server for PC ?
In a previous article, MSNIDER@rapnet.sanders.lockheed.com (Marc Snider) says: >Does anyone out there know of a BOOTP server implementation which will run >under either DOS or Windows? > The FAQ does. This is all straight from it. (Except for the comments in brackets). Hope this helps you. ---------------- B-12. What NetWare TCP/IP NLMs are out there and how do I get them to work? A public and known to work reliable TFTP and BOOTP daemon for NetWare OS 3.1x/4.0x and NetWare/IP are available from ftp.novell.de at ~/pub/netwire/unsupported/server/bootpd.exe. Contact: dirk@rhein-main.de --------------- Recommendation BOOTP Free A bootp server available via file://biochemistry.cwru.edu/pub/dos/bootp.zip or file://ftp-ns.rutgers.edu/pub/msdos/wattcp/bootp.zip --------------- Downright Speculation LPD Free FTP and BOOTP server included This software is a freeware line printer daemon as well as an FTP and BOOTP server. Available via file://tacky.cs.olemiss.edu/pub/lpd/lpd.zip, lpdsrc.zip [This is the one we use at University of Wisconsin - Stevens Point] -------------- Andy -- Andy Berkvam | Few are wholly dead: U of Wisconsin - Stevens Point | Blow on a dead man's embers Cleveland Freenet: bq274 | And a live flame will start. Internet: aberkvam@spbsd1.uwsp.edu | -Robert Graves
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: 11 Jun 1994 08:51:26 GMT From: tli@cisco.com (Tony Li) To: comp.protocols.tcp-ip Subject: Re: Bootp: Across routers/Segments/Etc. ?
In article <treynold.35.000FCE6D@fred.lasalle.edu>
treynold@fred.lasalle.edu (Tommi) writes:
I've recently been fiddling with using bootp to try and dish out
IP's for a small subnet which will eventually contain some slip and ppp
access points. My problem is this: The segment I am setting up
will be the 13 segment (xxx.xxx.13.xxx), which will be connected via
router to the 10 segment. On the 10 segment rest several of our un*x
machines, including the linux box which plans on running bootpd. I
don't want to move the linux box to the 13 segment. Isn't bootp
supposed to travel over routers, much like rarp would not?
Yes, if you configure the router properly.
I thought that I remembered reading this a while ago (has been a while
though...), but monitoring the traffic on the new 13 segment as I tried
to get a request across to the 10 showed several broadcast udp packets
at fixed intervals from the client. Now, certainly realizing that a
router should not in any case forward a broadcast packet, is there any
way to get bootp across a router??? (the routers are, currently,
running md-dosip routed (yes, I know, get a real router :)
Problem solved. ;-) Yes, it does require special code to forward bootp.
Also, will bootp allow for me to eventually distribute ip's from a
certain sort of "available ip" pool rather than by ethernet address, so
that I can accomodate ppp ???
Yes. It's called Dynamic Host Configuration Protocol (DHCP). It's based
on Bootp.
Tony
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: 11 Jun 1994 08:55:09 GMT From: tli@cisco.com (Tony Li) To: comp.protocols.tcp-ip Subject: Re: Subnetting with multiple nets
In article <2ta30sINN88b@jumbo.read.tasc.com> underlan@jumbo.Read.TASC.COM
(Samuel L/ Underland) writes:
I have a question about OSPF and subnetting with two different Class C
addresses. I have a configuration, pictured below, with a central hub
router and numerous remote sites. I want to subnet but don't have enough
subnets (allowing for expansion) within the range for one Class C address.
OSPF doesn't permit routing from a subnet in one network through a
different network, to a subnet of the originating network.
OSPF explicitly _allows_ this. That's not to say that it necessarily makes
sense for you.
I would like to divide the
available address space approximately evenly among the sites.
Questions:
1) When I route through a Hub system (AGS+ in this case), which network
is it considered part of? A, B, or Both?
Both.
2) Will the Hub router route from all combinations of A and B? Does it
matter what the LAN is at the Hub site?
All. No.
3) Is making this work vendor or software rev dependent?
No, at least not from what you've said here.
Tony
Configuration:
central site LAN (subnet A.A.A.n)
----------------
|
----------------
| Hub Router |
---------------- Remote LANs
| | | | | |
| | | | | --A.A.A subnet1
| | | | ----A.A.A subnet2
| | | ------A.A.A subnetn-1
| | --------B.B.B subnet1
| ----------B.B.B subnet2
------------B.B.B subnetn
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: 11 Jun 1994 11:05:56 GMT From: droms@regulus.cs.bucknell.edu (Ralph E. Droms) To: comp.protocols.tcp-ip Subject: Re: Where to find pointers to DHCP discussions?
The mailing list host-conf@sol.cs.bucknell.edu is focused on DHCP (admin requests to host-conf-request, please). RFCs 1541, 1533 and 1534 (sic) give the current DHCP specs. -- - Ralph Droms Co-Director, Computer and Communication Services droms@bucknell.edu Associate Professor of Computer Science (717) 524-1795 Bucknell University (717) 524-1790 (fax) Lewisburg, PA 17837
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: Sat, 11 Jun 1994 17:25:49 GMT From: todds@Newbridge.COM (Todd Sandor) To: comp.protocols.tcp-ip Subject: Non-blocking accept()...
I'm implementing an application that uses non-blocking TCP sockets under SunOS 4.1.X and have a question concerning using the accept() call on the non-blocking server socket fd. Assumption: - the accept() is used only when the server socket fd indicates something to read on it via the select() system call. Question: Given the above assumption would accept() ever return -1 with the errno set to EWOULDBLOCK? If it does, how do I get it to do it? ========================================================= I've implemented a tcp server in the above manner, but havn't had accept() return -1 with errno set to EWOULDBLOCK in the testing I've done so far, ... but ... (I know if the select() call etc. is not used this can happen, but can it "theorically" happen if the select() call indicates there is something to read of the socket descriptor?).... -- OSI buys you the promise of richer applications than the IP suite, at the cost of immaturity, complexity, inefficiency and incompleteness (unknown author). Todd Sandor Newbridge Networks: Kanata, Ontario Canada todds@newbridge.com Phone: 591-3600 (ext 1011)
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: Sat, 11 Jun 1994 20:56:58 GMT From: kangs@minerva.cis.yale.edu (Sung Moon Kang BK94) To: comp.protocols.tcp-ip Subject: Appletalk through tcpip (clarification)
This is a clarification of the question I posted several days ago about
tunnelling Appletalk through tcp-ip.
What I should have asked is if there was something I could run on two
*personal* Mac's so that... say I have a friend at Stanford running it,
I (at Yale) could open something so that I get the chooser that my
friend at Stanford sees, and vice versa.
The answers that I have gotten so far all indicated that Appletalk
tunneling through tcpip is done already by routers (such as those made
Gatorboxen made by Cayman, etc). Although something like that would
effectively join two campuses Appletalk networkes, it would also require
the coporation of the two system adminstrative bodies... which always
doesn't happen.
I was wondering if anyone know of an application/extension/whatever I
can run on a personal Mac (one at each campus) that will let me access
another campus's Appletalk network through tcp-ip (internet).
Please mail your replies to kangs@minerva.cis.yale.edu. I will post a
followup with the answers I collect.
Thanx very much.
--
---------------------------------------------------------------------------
Sung Moon Kang BK 94 | "You don't belong in this century
kangs@minerva.cis.yale.edu | do you, Sung?"
| - Richard Cho 5/30/94
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: 11 Jun 1994 21:22:15 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: ICMP Redirect THEN Host Unreachable?
In article <3928@wcc.oz.au> tom@wcc.oz.au (Tom Evans) writes:
>H1 sends a packet (an ICMP Ping reply) to H2, but via R1 (its default gateway).
>R1 forwards the packet via R2 to H2, and sends an ICMP Redirect to H1. Fine.
>Then R1 sends an ICMP Host Unreachable to H1 for the same packet. Not fine.
Seems wrong to me. Host Unreachable should only be sent if the router has
no route to the destination. If it can send a redirect for the destination
then it obviously thinks it's reachable.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 12 Jun 1994 05:09:56 GMT From: easu586@rigel.oac.uci.edu (Dave Rosenberg) To: comp.dcom.lans.ethernet,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Can I get a Class B Address Assisgnment
-- Dave R.
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Jun 1994 03:33:30 -0800 From: len@netsys.com (Len Rose) To: comp.protocols.tcp-ip Subject: Documenting "discard" service
Can anyone point me to anything that really documents the inet "discard" service? I've looked through the source and I'd like more background.. Thanks.. Len -- "What a long strange trip it's been..." or "Gee, I am free..." "http://www.netsys.com" --- Len Rose, 415-233-0441 (voice) len@netsys.com
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: 12 Jun 1994 22:41:38 GMT From: desilva@ee.tamu.edu (Buveneka K Desilva) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Printing via a Printer connected to an ethernet line?
Hi Netters, I assume this is the correct newsgroup. If not please do excuse! We have a couple of DOS/Windows based 486's with Ethernet connections and some workstations, all of which are connected to the net. We are interested in connecting a fast printer via an ethernet adapter to the campus network and sharing the printer. The questions I have, 1. Is there a driver or some method to install this printer for windows printing? (is it possible to do this?) 2. If not can it be done thru a tcp-ip based utility (such as Winqvt or some other)? 3. I know that the sun's can print via an ethernet printer, but is it possible to have 2 or more W/S or/and Servers accessing it directly 4. Any other pointers? Thank you'll. Appreciate a quick response, -kanishka deSilva
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Jun 94 02:51:13 GMT From: amolitor@blefscu.network.com (Andrew Molitor) To: comp.protocols.tcp-ip Subject: Re: What is the MTU of FDDI?
A couple people have pointed out that RFC1188 says flatly that 4352 bytes is the MTU for IP and ARP, so that's that, and it's right. If you're doing IP on a FDDI ring, use an MTU of 4352 regardless of whether or not you've got an NSC router or NSC manual which says 4470 is good. However, for non-IP/ARP datagrams, you still get 4470, or a little more if you decide not to use SNAP. Andrew
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Jun 94 13:43:00 -0600 From: mark.stapleton@cld9.com (Mark Stapleton) To: comp.protocols.tcp-ip Subject: Looking for Whois Client
ML>I am looking for a Whois Client or Server application for Windows. ML>Hopefully freeware. If anyone knows where I can ftp it from, it ML>would be greatly appreciated. Can't help you with freeware, but NetManage's Chameleon has it. Mark -30- --- þ CmpQwk #UNREGþ UNREGISTERED EVALUATION COPY
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 1994 12:12:26 -0500 From: gpalmer@blue.weeg.uiowa.edu (Gary Palmer) To: comp.protocols.tcp-ip Subject: BOOTP and NCSA Telnet
I am having trouble in getting the myip=BOOTP to work with the latest release of NCSA Telnet, 2.3.07. It seems that the FTP client works fine with this parameter, but if I don't specifiy an exact ip address with myip=, Telnet will eventually come back with an error that it cannot communicate with a BOOTP server. Again, I think I have the server working, because it satisifies FTP, and it satisifies other TCP/IP software that I've been working with, like WINSOCK, but NSCA Telnet 2.3.07 it does not. Has anyone come across this problem?
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 94 04:19:43 GMT From: smiller@jafar.qualcomm.com (Scott Miller) To: comp.protocols.tcp-ip Subject: PPP/CHAP
Are there any public domain/shareware versions of CHAP for PPP out there? Any help would be appreciated. Scott Miller <smiller@qualcomm.com> QUALCOMM Incorporated
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 1994 04:27:30 GMT From: iddasl@iddis.com (Alan Siping Liu) To: comp.protocols.tcp-ip Subject: IP multicast: igmp library?
Hi everyone, I am trying to do IP multicast on Sparc10 under Solaris 2.3. I find igmp.h file in directory /usr/include/netinet but cannot find library file for the functions defined in the header file. Can anyone help? Thanks a lot. - Alan
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 1994 07:54:10 GMT From: jel@tel.vtt.fi (Jerry Lahti) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: Printing via a Printer connected to an ethernet line?
It depends quite a lot on the Ethernet connected printer you are using. For example, the HP Laserjet 4Si with the JetDirect card is able to support several printing protocols at the same time. This allows UNIX hosts to print using TCP/IP while Windows for Workgroups workstations can use a DLC based printing protocol with a special printer driver provided by HP. Mixed access is possible, because the clients can be set up the tear down the printer connection after each job. Note that this does not work with lower-end or older HP printers because they are constrained to using a single printing protocol, selected by the first client which uses the printer. I'm sure other manufactures have printers with similar capabilities. -- Jerry Lahti |Voice:+358 0 456 5624, Fax:+358 0 456 7013 Technical Research |Internet: Jerry.Lahti@vtt.fi Centre of Finland (VTT) |X.400: C=FI,ADMD=MAILNET,PRMD=VTT,PN=Jerry Lahti
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Jun 1994 09:12:58 GMT From: smithm@lincoln.gpsemi.com (Matt Smith) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: Printing via a Printer connected to an ethernet line?
In article <2tg2v2$q37@news.tamu.edu> desilva@ee.tamu.edu (Buveneka K Desilva) writes: >From: desilva@ee.tamu.edu (Buveneka K Desilva) >Subject: Printing via a Printer connected to an ethernet line? >Date: 12 Jun 1994 22:41:38 GMT >Hi Netters, >I assume this is the correct newsgroup. If not please do excuse! >We have a couple of DOS/Windows based 486's with Ethernet connections >and some workstations, all of which are connected to the net. >We are interested in connecting a fast printer via an ethernet adapter >to the campus network and sharing the printer. >The questions I have, >1. Is there a driver or some method to install this printer for windows > printing? (is it possible to do this?) >2. If not can it be done thru a tcp-ip based utility (such as Winqvt or > some other)? >3. I know that the sun's can print via an ethernet printer, but is it > possible to have 2 or more W/S or/and Servers accessing it directly >4. Any other pointers? We have the same sort of set up that your looking for. We use a HP JetDirect box that plugs into Ethernet and in my opinion they are pretty good. You get software that turns either a PC or a Server (Windows/Lan Manager/NT) into a print server and it will also use TCP/IP although you do need a Bootp server to configure it. These are all at the same time. We have one accepting prints from a PC network, from a VAX, and from a UNIX machine. Hope this is of some help. Matt
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Jun 1994 09:28:41 GMT From: rsgawera@fiveg.icl.co.uk (Raj Gawera) To: comp.protocols.tcp-ip Subject: Bootp
Dear netters, What is bootp ? Is it described in the FAQ? yours briefly but to the pointly, Raj Gawera
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 1994 18:24:52 -0400 From: jcarroll@panix.com (Jim Carroll) To: comp.protocols.tcp-ip Subject: lpr protocol impementation details
We have a rather technical problem with the lpd protocol. We are submitting a job to a remote Sun/Unix system using the lpr protocol. The server is however responding with NACK(107) to our request for "Receive a Printer Job" command (0x02). We have verified that the host making the request is in the /etc/hosts file, and that /etc/hosts.equiv and /etc/hosts.lpd are both set to +. We have also tried 'lpr'ing the job from a DOS box, and it appears to work. Does anyone have any idea as to what a NACK-107 response from the lpd means? Thanks Jim C. -- ************************************************ * Infinite Diversity, in Infinite Combinations * ************************************************
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 94 12:19:07 GMT From: tom@wcc.oz.au (Tom Evans) To: comp.protocols.tcp-ip,comp.dcom.sys.wellfleet Subject: Re: ICMP Redirect THEN Host Unreachable?
In article <3928@wcc.oz.au>, tom@wcc.oz.au (Tom Evans) writes:
> I've got a packet trace here that looks WEIRD to me. There's two
> famous-name IP routers on a backbone with a host, call them R1, R2 and
> H1. There's another host on the other side of R2 - call it H2:
>
> [ R1 ]============[ R2 ]======[ H2 ]
> ||
> [ H1 ]
>
> H1 sends a packet (an ICMP Ping reply) to H2, but via R1 (its
> default gateway). R1 forwards the packet via R2 to H2, and sends
> an ICMP Redirect to H1. Fine. Then R1 sends an ICMP Host
> Unreachable to H1 for the same packet. Not fine. This doesn't
> seem to be what the RFC says. Any opinions? Is this legal?
I got mail from "THE famous router vendor" asking if R1 was them, and
expressing the opinion that R1 isn't playing by the rules. By chance
R2 happens to be a Cisco :-), but R1 is a "Wellfleet model FN
running 5.75 software".
Here's a packet dump. The customer has asked me to disguise his IP
addresses and machine names - the first two bytes of all IP
addresses have been changed to "xx.yy" and the checksum is "zz zz"
to stop clever people from reconstructing the IP addresses in spite
of this :-)
icmp type
lnth proto source destination src port dst port
70 icmp gw megan redirect
00 00 18 00 08 66 00 00 a2 01 28 9c 08 00 45 00
00 38 ee 34 00 00 1e 01 zz zz xx yy 44 01 xx yy
44 05 05 01 b3 8d xx yy 44 02 45 00 00 54 fc d8
00 00 3b 01 zz zz xx yy 44 05 xx yy 48 02 00 00
47 6e 32 28 00 3e
70 icmp gw megan dst unreachable
00 00 18 00 08 66 00 00 a2 01 28 9c 08 00 45 00
00 38 ee 35 00 00 1e 01 zz zz xx yy 44 01 xx yy
44 05 03 01 83 2a 00 00 00 00 45 00 00 54 fc d8
00 00 3b 01 zz zz xx yy 44 05 xx yy 48 02 00 00
47 6e 32 28 00 3e
========================
Tom Evans tom@wcc.oz.au
Webster Computer Corp P/L, 11 Glenvale Crescent Mulgrave, Melbourne 3170
Victoria, Australia 61-3-561-9999 FAX ...560-0067 A.C.N. 004 818 455
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 94 13:16:52 GMT From: bparker@pilot.njin.net (Bruce Parker) To: comp.protocols.tcp-ip,comp.security.unix Subject: Re: Is IP source routing a bad idea?
treynold@fred.lasalle.edu (Tommi) writes: >In article <1994Jun6.032935.17859@martha.utcc.utk.edu> venu@voodoo.utcc.utk.edu (Nair Venugopal) writes: >[stuff deleted] >>2) Is there any situation, other than trouble shooting, where >>the source routing option will be of use? >Not as far as I can think of off hand; about the only thing that I can think >of/remember that source routing is used for is (as you mentioned) when >troubleshooting--it can eliminate the possibility of different packets >taking different routes along their merry way... Bhagwat and Perkins (Mobile and Location-Independent Computing Symposium), Johnson (CMU TR), and Rekhter and Perkins (Internet draft "Loose Source Routing for Mobile Hosts") use LSR to allow mobile hosts to retain the same IP address while moving through the internet. Cheers, Bruce -- Bruce Parker 4314 Infotech (201) 596-3369 Computer and Information Science Department parker@vienna.njit.edu New Jersey Institute of Technology, Newark, New Jersey 07102 USA
-----------[000255][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Jun 1994 13:56:19 GMT From: prodrig@gundam.batdd (Paul) To: comp.protocols.tcp-ip Subject: TCP ports
Hello; I'm hoping someone can answer a couple of basic questions, or help me to get started on the right track by letting me know where some of this information can be obtained. What I'm trying to do is connect a vax to a sparc station and use TCP for data transfer. Thank you very much in advance. 1. When establishing a TCP connection, how does one determine what the port numbers will be in use on both machines? 2. When transfering data between a vax and a sparc station, will the data be transfered in a pre-determined format such as binary or ASCII, or will both users have to determine which format will be used in advance.
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Jun 94 23:30:03 -0500 From: baldwinl@delphi.com To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
Tom Graham <ucistdg@st.unocal.COM> writes: >Just recently saw this for myself!!!! User complaning that TCP/IP files >transfers were taking forever. Did a Sniffer trace, saw dropped packets >and retransmission times of 16 seconds!!! Talk about a snails pace. That can be normal if it was the 8th attempt to retrasmit the same packet. What you want to see is the initial delay to retransmit the packet (excuse me, the segment) the FIRST time. My problem was that IBM's TCP for OS/2 enfources a MINIMUM retransmission timeout of 1000-1500ms. Meaning that if you drop a packet it will be 1 - 1.5 seconds before you even TRY to retransmit, REGARDLESS of the actual normal round trip response time. THIS kind of delay is too excessive for local LAN segments, but very appropriate for low-speed wide area links. I don't know what implementation of TCP you are using but thre (there) may be parameters that allow you to configure this timeout value. Rememember, however, that speeding retranmission can increase congestion--making the problem even worse. You have to be careful and understand where you're dropping packets and why. Move the Sniffer from one segment to another and determine exactly where you're dropping packets.
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 1994 15:26:19 GMT From: brawls@beeblebrox (Brad Rawls) To: comp.protocols.tcp-ip Subject: OSPF and address maintenance
Can anyone identify whether "canned" software packages exist that perform IP address administration for you automatically? Specifically, we have an environment with multiple class B's, many class C's using OSPF and BGP. VLSM's are being employed on a global nature. Any ideas for IP address administration short of custom coding or database? -- ---------------------------------------------------------------------- | Brad Rawls Work: 703-708-1176 | | Citicorp Global Information Network Fax: 703-708-1184 | | 1900 Campus Commons Dr. brad.rawls@mail.citicorp.com | | Reston, VA 22091 | | Mail Stop 3/8 | ----------------------------------------------------------------------
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Jun 1994 16:29:55 +0000 From: ggoodey@sblack.demon.co.uk (Graham Goodey) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: Printing via a Printer connected to an ethernet line?
Kanishka, We are using a HP 4M with a Jet Direct Card and a serial line connection (for historic reasons) - works perfectly. The advantage of this over the Jetdirect box is that there isn't another box and power cables hanging around. You also *don't* need bootp, which I didn't think you needed with the box but I don't have 1 of those and I bow to experience of a box owner. However, you can use a bootp server should you wish. I am just about to purchase an HP 4M+ based on my experiences which now comes with the Jetdirect card already installed (TCP/IP, appletalk, etc). hope this is of help regards Graham -- Graham Goodey Internet: ggoodey@sblack.demon.co.uk
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Jun 94 16:41:57 GMT From: thssaaf@iitmax.iit.edu (Abdulkader A. Al-Fantookh) To: comp.protocols.tcp-ip Subject: A transport Protocol Simulator is needed
Hello everybody, Currently, I'm in a process of evaluating some transport protocol techniques. I really need a simulator that I can use for this evaluation. For example, I will give the simulator several parameters including, the speed of the link, the speed of the processor, checksum, packet size, and some others. In the second run, I will give the same parameters except that I will change the packet size, and then compare the two runs. Thanks. -Abdul Alfantookh Illinois Institute of Technology Phone : (708)594-0475
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 1994 15:12:39 +0100 From: robjan@rabo.nl (Rob Janssen) To: comp.protocols.tcp-ip Subject: Re: Documenting "discard" service
In <len-130694033330@fx.netsys.com> len@netsys.com (Len Rose) writes: >Can anyone point me to anything that really documents the >inet "discard" service? I've looked through the source and >I'd like more background.. Thanks.. Try RFC 863 Rob
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 1994 17:10:02 GMT From: Adam Wildavsky <adamw@panix.com> To: panix.questions,panix.internet.slip,panix.internet.ppp,comp.protocols.tcp-ip Subject: Re: Mosaic conflict?
In article <2skm4t$d2u@panix.com> Arthur Cinader, acinader@panix.com writes: > I have mosaic 1.03 on my Quadra 800. When I launch it, I get > "Unable to connect to remote host" in the status bar and "text > has not been loaded" in the text box. ... (more details omitted) > Any ideas, recommendations? What happens when you open a local html file? > Anybody know the developers address so I can mail them a copy > of this letter? According to the NCSA Mac home page http://www.ncsa.uiuc.edu/SDG/Software/MacMosaic/MacMosaicHome.html it's mosaic-mac@ncsa.uiuc.edu. AW
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 1994 20:00:29 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip,comp.unix.aix Subject: Re: IP Adressing of Multiple Interfaces
In article <2tabiq$173t@source.asset.com> danglert@source.asset.com (Terry Dangler) writes:
>We are using an RS/6000, is there any reason why the following IP
>addressing scheme would not work:
>
>Ethernet Interface IP Address: 192.131.125.10 connects to gateway and Internet
>SLIP Interface IP Address: 192.131.125.25 attached to Xstation
>Token Ring Interface IP Address: 192.131.125.33 connects to LAN
You haven's said what your subnet mask is. Assuming it's just the default
mask for a class C network, the above won't work. All those addresses are
on the same subnet, so the interfaces must all be connected to the same
physical (possibly bridged) network.
If your network uses a subnet mask of 255.255.255.240 then the above
addressing scheme would work. But this subnet mask only allows 14 nodes
per subnet.
--
Barry Margolin
System Manager, Thinking Machines Corp.
barmar@think.com {uunet,harvard}!think!barmar
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: Tue, 14 Jun 94 07:30:00 -0640 From: john.will@dscmail.com (John Will) To: comp.protocols.tcp-ip Subject: NIS <----> PCNFS problem
J > All works fine, but in Windows 3.1, pc-nfs' network services J >(telnetw, ftpw and others) only use the NIS map (Hostmap) and doesn't J >resolve in the name server host. J > J > What shall I do to correct this problem?, i.e., pc-nfs' services J >under Windows work with the name server host. Wait until Sun's PC-NFS supports something other than NIS? :-)
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 1994 21:09:32 GMT From: abch91@control.auc.dk (alex bo christensen) To: comp.protocols.tcp-ip Subject: how to get local inet. addr ?
I have a simple problem, but it seems hard to solve. To problem is : A program runs on a host in a network, and is going to use the internet address for this host. Is it possible to get this internet addresse, and how ? The os is SunOs solaris. Compiler gcc
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: 13 Jun 94 21:15:59 GMT From: jkay@cs.ucsd.edu (Jon Kay) To: comp.protocols.tcp-ip Subject: Re: What is the MTU of FDDI?
In article <Cr5M2B.GzB@calcite.rhyolite.com> vjs@calcite.rhyolite.com (Vernon Schryver) writes: >4352 was choosen in a long ago FDDI birds-of-a-feather InterOp meeting. > >I like to use 4096 of payload in TCP kernel code to go fast, but that's >ok because since there is no law that says you must transmit full-siced >frames. You need only be prepared to accept bigger frames. I like 4352 for an if_mtu because most networked workstations do orders of magnitude more NFS than TCP, and needing to process 3/2 as many packets for 8k data transmissions does take significantly more time. However, most TCPs incorporate rounding down to MCLBYES, so if that's 4096 bytes and your page size is 4k, and you implement page flipping, you can have your cake and eat it too. Jon
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 04:50:37 -0400 From: r6788@hopi.dtcc.edu (Joe Rach) To: comp.protocols.tcp-ip Subject: get_user_name()???
Hello,
I was wondering if there is a function that will return a user's login
name from a socket. I've got gethostname, etc.. working and want to varify
login names. Some ftp servers from what i've been told can do this.
Any pointers to information would be greatly apriacted...
Thanks in advance,
Newby at TCP/IP...
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: Mon, 13 Jun 1994 22:39:09 GMT From: ucistdg@st.unocal.COM (Tom Graham) To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
In article <2sobsf$jdv@news.ccit.arizona.edu>, Aaron Leonard <Leonard@Arizona.EDU> wrote: > >In article <2snnej$em0@news.CCIT.Arizona.EDU>, leonard@telcom.arizona.edu >(Aaron Leonard) writes: >[...] >|| With a Sniffer, it seems to take nearly two >||seconds for TCP to recover from a single dropped packet. After reading up >||on TCP retransmission algorithms it almost seems like this is normal. >| >|Yup, that's just about normal--although the actual retransmission >|delay will be based upon TCP's estimated round-trip time. >| [...] >|For a nice gory practical discussion, see chapter 21 in Stevens' >| Just recently saw this for myself!!!! User complaning that TCP/IP files transfers were taking forever. Did a Sniffer trace, saw dropped packets and retransmission times of 16 seconds!!! Talk about a snails pace. This was caused by hub/repeater that does not like to pass large packets!! That is, with packet sizes starting at about 1200 bytes, the hub drops more as the packets get larger. Just posted this in comp.dcom.lans.ethernet. Looking for validation or a sanity check on this, hubs that like only small etherner packets. The user was saying, "TCP/IP stinks, IPX is much faster". Any input anyone???? Tom -- Tom Graham Unocal Corporate Information Services Phone: (714)693-5808 5460 E. La Palma Ave. Internet: tom.graham@st.unocal.com Anaheim Hills, Ca 92807
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: Tue, 14 Jun 1994 00:48:38 GMT From: atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson) To: comp.protocols.tcp-ip Subject: Re: lpr protocol impementation details
In article <2timbk$roi@panix.com> jcarroll@panix.com (Jim Carroll) writes: > We have a rather technical problem with the lpd protocol. We are submitting > a job to a remote Sun/Unix system using the lpr protocol. The server is > however responding with NACK(107) to our request for "Receive a Printer > Job" command (0x02). > > We have verified that the host making the request is in the /etc/hosts > file, and that /etc/hosts.equiv and /etc/hosts.lpd are both set to +. > > We have also tried 'lpr'ing the job from a DOS box, and it appears to work. > Does anyone have any idea as to what a NACK-107 response from the lpd > means? With lpr/lpd it is usually best to start by looking at the BSD sources. BSD sources for this sort of thing are probably available online from ftp.uu.net someplace. There is an RFC on the protocol, but the RFC came out long after the program was widespread and isn't all that definitive in practice. Ran atkinson@itd.nrl.navy.mil
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: Tue, 14 Jun 1994 00:55:23 GMT From: atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson) To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
In article <CrCxL9.Cty@unocal.com> ucistdg@st.unocal.COM (Tom Graham) writes: > > Just recently saw this for myself!!!! User complaning that TCP/IP > files transfers were taking forever. Did a Sniffer trace, saw dropped > packets and retransmission times of 16 seconds!!! Talk about a snails > pace. This was caused by hub/repeater that does not like to pass > large packets!! That is, with packet sizes starting at about 1200 > bytes, the hub drops more as the packets get larger. Just posted this > in comp.dcom.lans.ethernet. Looking for validation or a sanity check > on this, hubs that like only small etherner packets. The user was > saying, "TCP/IP stinks, IPX is much faster". > > Any input anyone???? Yes. The "Path MTU Discovery" technique documented in a standards-track RFC can often be helpful in such circumstances. However, if one or more of the critical components is badly enough implemented to drop legal packets, that same component is not likely to be implementing Path MTU Discovery. Hence, Path MTU Discovery doesn't always help. The bug you describe is in the hub/repeater, which might not even be implementing IP or ICMP. If you can manually set the MTU size on the host interfaces, you might be able to work around it. This is not demonstrating that IPX is better; IPX is just getting lucky. Ran atkinson@itd.nrl.navy.mil
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 11:45:54 -0500 From: lin@cs.purdue.edu (John Chueng-Hsien Lin) To: comp.protocols.tcp-ip Subject: Re: Telnet response time after packet drop?
In article <R69N39r.baldwinl@delphi.com>, baldwinl@delphi.com writes: > Tom Graham <ucistdg@st.unocal.COM> writes: > > >Just recently saw this for myself!!!! User complaning that TCP/IP files > >transfers were taking forever. Did a Sniffer trace, saw dropped packets > >and retransmission times of 16 seconds!!! Talk about a snails pace. > > That can be normal if it was the 8th attempt to retrasmit the same packet. > What you want to see is the initial delay to retransmit the packet > (excuse me, the segment) the FIRST time. > My problem was that IBM's TCP for OS/2 enfources a MINIMUM retransmission > timeout of 1000-1500ms. Meaning that if you drop a packet it will be > 1 - 1.5 seconds before you even TRY to retransmit, REGARDLESS of the > actual normal round trip response time. THIS kind of delay is > too excessive for local LAN segments, but very appropriate for > low-speed wide area links. Under normal operating condition, a LAN should not drop TCP packets often (it it does, then something must be broken). For an interesting discussion about the reasons for setting a lower bound on TCP Retransmission Time-Out (RTO) and how to determine it without accessin the TCP source code, see the following paper: ftp:gwen.cs.purdue.edu:/pub/lin/probing.TCP.ps.Z John Lin (lin@cs.purdue.edu)
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 11:46:23 -0500 From: dpm@bga.com (David P. Maynard) To: comp.protocols.tcp-ip Subject: Re: bootp server response times
Paul J Lustgraaf <grpjl@iastate.edu> wrote: >Charl Barnard <charl@pondermatic.ee.up.ac.za> wrote: >> >>My problem is that the server takes extremely long to respond, and >>quite often doesn't respond at all. Sometimes (usually shortly after >>previous attempts, the server responds instantaneously ! > >Don't use inetd to start bootpd. Run it in standalone mode. >The CMU version, at least, supports a -s switch to make bootpd run >as a daemon. Try it, you'll like it. Agreed. Standalone operation will likely solve many of your problems. If your config file is large, it takes a long time to start up the server. However, an apparently related problem is that a lot of the DOS/Mac client software isn't very forgiving of "slow" BOOTP servers. It seems to be fairly common to fire off a half-dozen requests at 1-second intervals and give up if an "acceptable" reponse isn't received. Some packages apparently check the sequence number because they ignore responses from previous requests. That means the response must come back in under 1 second. (I haven't verified this, but some clients have logged the behavior.) For a SLIP line, the 1-second turnaround requirement is pretty marginal. -dpm -- David P. Maynard, Carnegie Mellon University & Dependable Solutions USMail: 14312 Richard Walker Blvd, Austin, TX 78728-6862 EMail: dpm@depend.com, Tel: +1 512 251 8122, Fax: +1 512 251 8308 --
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 07:59:37 GMT From: visser@convex.com (Lance Visser) To: comp.protocols.tcp-ip Subject: Re: TCP ports
In <CrC9Dw.GsD@pica.army.mil> prodrig@gundam.batdd (Paul) writes: >Hello; +> I'm hoping someone can answer a couple of basic questions, or help me to get started on the right track by letting me know where some of this information can be obtained. What I'm trying to do is connect a vax to a sparc station and use TCP for data transfer. Thank you very much in advance. Go pick up a book on socket programming (or Unix network programing). You could also read the bind(2) and connect(2) man pages on the sparc. IF the vax is running ULTRIX, there should be documentation or man pages for sockets. If the vax is running VMS or something else, then I would suggest looking at any documentation the vax has for clues. +>1. When establishing a TCP connection, how does one determine what the port numbers will be in use on both machines? The bind() and connect() system calls determine what ports should be used. If you dont pick a local port, tcp will assign one for you. The "server" side of the connection is usually bound to a port you know so that the client can find it. The client can either specifically bind to a local port or let tcp assign it a default port at random. The client establishes the connection with the server via the connect() system call. In the connect syscall is specified the server "port" you wish to connect to. +>2. When transfering data between a vax and a sparc station, will the data be transfered in a pre-determined format such as binary or ASCII, or will both users have to determine which format will be used in advance. TCP is a byte stream protocol. There is no pre-determined format You are pushing a stream of 8-bit bytes from one side to the other. Binary and ascii are FTP concepts put on top of tcp.
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 08:27:57 GMT From: i.ellery@uea.ac.uk (Ian Ellery) To: comp.protocols.tcp-ip Subject: Re: NIS <----> PCNFS problem !
In article <1994Jun10.201135.13478@lauca.usach.cl>, jprado@lauca.usach.cl (Jorge Andres Prado Troncoso) says:
> We are running PCNFS 5.0 under Ultrix 4.3 (DEC System 5000/240)
>and yellow page (yp).
> All works fine, but in Windows 3.1, pc-nfs' network services
>(telnetw, ftpw and others) only use the NIS map (Hostmap) and doesn't
>resolve in the name server host.
Either wait for 5.1 which is finally supposed to do this, or get your NIS
hosts map to 'fail over' to the DNS. PCNFS still looks up hostnames in
the NIS, but if it is not in your local hosts map, NIS will send out a DNS
request and get the hostname. You need to add a '-d' flag somewhere
in the NIS makefile - sorry been a while and I can't see a manual.
hope this helps,
Ian
----
Ian Ellery, Computer Centre, UEA, Norwich, Norfolk, NR4 7TJ, UK
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 20:20:14 -0700 From: dcrane@crl.com (David Crane) To: comp.security.misc,comp.protocols.tcp-ip Subject: Re: Query: trusted routers
Ran Atkinson (atkinson@sundance.itd.nrl.navy.mil) wrote: : In article <2tk9jp$auh@gabriel.resudox.net> sharris@resudox.net (Sandy Harris) writes: : >Are there any packet filtering IP routers evaluated for : >interesting security levels, American B's or some other country's : >standard? : I understand that Advanced Computer Communications Systems (ACC : Systems) has a fairly new product named "Stealth" which is targeted at : an Orange Book/Red Book B3 level. ACC Systems has indicated that they : are submitting it to NCSC for formal evaluation. I'm pretty sure that : final evaluation is not yet complete. You might contact them directly : for more information. They have an office somewhere near Columbia, : Maryland, USA. The product is real -- they showed one in DC late last : week at the AFCEA tradeshow. It implements most normal routing : protocols. : To my knowledge that is the only router designed for formal : evaluation under both Orange Book and Red Book criteria. Its also the : only B3-targetted router I know about. I would guess that they'll get : a fair amount of business if they price it reasonably. It's my understanding that the essential problem with routers is that they are easily spoofed. What does one do to a router to make it really effective as a security wall? They aren't bright enough to question what they receive.
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: Tue, 14 Jun 1994 11:25:52 GMT From: steven@unipalm.co.uk (Steven Vincent) To: comp.protocols.tcp-ip Subject: Re: FTP PCTCP ---> HP1200C Jet Direct?
temp@sneezy.cc.utexas.edu (Lee Thomas) writes: >Hi, >I just bought an HP 1200C color printer with an ethernet card (Jet Direct). >I need to print to it from an IBM RS/6000 using TCP/IP and PC's with FTP's >PCTCP software. Does anyone have any ideas or specific instructions on how >to get either system to print to the HP 1200C using TCP/IP? Please E-mail >me if you have a solution or ideas. For PC/TCP there are two options at least! Depending on the jet direct card in use PC/TCP might be able to use the LPR protocol to talk to it directly. (This is for Jet Direct cards that support lpr/lpd functions). Alternativly "Iprint -b 9100 <filename>" with the IP address of the Card set as the Imagen-print-server in pctcp.ini often works. This is brute force no spooling. Be carefull using lots of PC's direct to the Jet Direct cards as they will not spool the jobs and let the PC's go. Its far better to send the jobs to a central queue on the RS/6000 from which a single stream feeds to the printer. Configuring the AIX for LPR/LPD is fairly straight forward via Smit, otherwise speak to IBM. >Thanks! >-Lee >--------------------------------------------------------------------------- >Lee Thomas Voice: (512)322-6386 >Systems Analyst FAX: (512)322-6350 >City of Austin Electric Utility Internet: temp@ccwf.cc.utexas.edu >---------------------------------------------------------------------------
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 11:36:17 GMT From: charl@pondermatic.ee.up.ac.za (Charl Barnard) To: comp.protocols.tcp-ip Subject: bootp server response times
Hi, I am trying to use bootp with all the networked DOS-type PC's running CUTCP on our segment. As a bootp server, I use an RS/6000 340, as it also does some bootp serving for dataless clients. My problem is that the server takes extremely long to respond, and quite often doesn't respond at all. Sometimes (usually shortly after previous attempts, the server responds instantaneously ! I have monitored the request broadcasts, and the PC's seem to broadcasting the bootp-requests correctly. Further, I can see that the inetd actually does start bootpd on the server, and a file bootpd.dump is created. The only thing it doesn't do, is respond ! I tried using a Linux box as server, with identical results. Is CUTCP the problem here ? Can anyone suggest s better way to debug ? Or is the bootpd source available somewhere ? Any suggestions would be appreciated. Charl Barnard (charl@ford.ee.up.ac.za)
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 12:02:49 GMT From: tudball@lis.pitt.edu (A. Bruce McDonald) To: comp.protocols.tcp-ip Subject: Re: ICMP Redirect THEN Host Unreachable?
Barry Margolin (barmar@think.com) wrote:
: In article <3928@wcc.oz.au> tom@wcc.oz.au (Tom Evans) writes:
: >H1 sends a packet (an ICMP Ping reply) to H2, but via R1 (its default gateway).
: >R1 forwards the packet via R2 to H2, and sends an ICMP Redirect to H1. Fine.
: >Then R1 sends an ICMP Host Unreachable to H1 for the same packet. Not fine.
I have seen the same thing with an AGS+.
: Seems wrong to me. Host Unreachable should only be sent if the router has
: no route to the destination. If it can send a redirect for the destination
: then it obviously thinks it's reachable.
: --
: Barry Margolin
: System Manager, Thinking Machines Corp.
: barmar@think.com {uunet,harvard}!think!barmar
-------------------------------------------------------------------------------
A. Bruce McDonald
tudball@icarus.lis.pitt.edu
University of Pittsburgh "All Good Things..."
Work Phone: (412) 624-9499
-------------------------------------------------------------------------------
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 12:45:44 GMT From: SPENCER@alpha.salem.ge.com (Andy Spencer) To: comp.protocols.tcp-ip,comp.protocols.nfs Subject: NFS Buffer size & MTU for enet/fddi
This problem may be related to the version of NFS that our O/S (LynxOS) is using, or the rev of the firmware in our router, but all in all I believe it is probably a basic issue. Here is our situation: +----------+ +-----------+ | Novell | Fiber (FDDI) +--------+ Ethernet | UNIX | |NFS Server|-------------------| Router |-------------| NFS Client| +----------+ +--------+ +-----------+ What we see it that nfs transfers from the Novell NFS server to the UNIX client often die. The client side (unfsio) is set for 10 2second retries but can be made to work if the nfs_rdsize is dropped to 1024 or below. Local (on the same ethernet) transfers work fine at larger buffer sizes. Watching the packets on the ethernet shows nfs (udp) packets of 1200 to 1500 byte packets consistently cause failure, but droping the rdsize to 512 somehow regulates the link so that packets on the wire are 600 or 700 bytes long and don't seem to cause problems. I strongly suspect it has something to do with the MTU of the different links, but don't under- stand how changing the rdsize regulates the flow differently if it is over the router rather than locally on the ethernet. Any help would be appreciated! Andy Spencer GE Drive Systems AESpencer@salem.ge.com 1501 Roanoke Blvd./Rm 287 (703) 387-7361 (Voice) Salem, VA 24153 (703) 387-8651 (FAX)
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: Tue, 14 Jun 1994 13:02:01 GMT From: youki-k@is.aist-nara.ac.jp (Youki Kadobayashi) To: comp.protocols.tcp-ip Subject: Routing protocol simulator?
Are there any simulation tool for routing protocols? (specifically OSPF?) How do OSPF folks know that the protocol operates properly? -- // Youki Kadobayashi <youki-k@is.aist-nara.ac.jp> // Graduate School of Information Science // Nara Institute of Science and Technology, Japan
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 13:36:01 GMT From: grpjl@iastate.edu (Paul J Lustgraaf) To: comp.protocols.tcp-ip Subject: Re: bootp server response times
In article <CHARL.94Jun14133617@pondermatic.ee.up.ac.za>, Charl Barnard <charl@pondermatic.ee.up.ac.za> wrote: > >I am trying to use bootp with all the networked DOS-type PC's running >CUTCP on our segment. As a bootp server, I use an RS/6000 340, as it >also does some bootp serving for dataless clients. > >My problem is that the server takes extremely long to respond, and >quite often doesn't respond at all. Sometimes (usually shortly after >previous attempts, the server responds instantaneously ! > >I have monitored the request broadcasts, and the PC's seem to >broadcasting the bootp-requests >correctly. Further, I can see that the inetd actually does start >bootpd on the server, and a file bootpd.dump is created. The only >thing it doesn't do, is respond ! > Don't use inetd to start bootpd. Run it in standalone mode. The CMU version, at least, supports a -s switch to make bootpd run as a daemon. Try it, you'll like it. -- Paul Lustgraaf "It's easier to apologize than to get permission." Network Specialist Grace Hopper Iowa State University Computation Center grpjl@iastate.edu Ames, IA 50011 515-294-0324
-----------[000281][next][prev][last][first]---------------------------------------------------- Date: Tue, 14 Jun 1994 13:41:01 GMT From: abell@velveeta.apdev.cs.mci.com (Andrew_Bell) To: comp.protocols.tcp-ip Subject: Read returns zero even when RST received.
Some postings have gone across here saying that if a read is pending when the RST is received from a remote side, then the read will return -1 and errno == ECONNRESET. If there is a bunch of stuff in the receive queue and you are reading along happily, I don't get a hint of a problem until the queue is empty. This is fine. When I have emptied the queue, I just get a result of 0 from my read, indicating a disconnect, but not necessarily an aborted connection. Is there anyway I can be sure I have gotten an aborted connection instead of just a close one? BTW, running AIX 3.2.5 on both sides. Andrew Bell MCI Communications abell@chong.nms.cs.mci.com
-----------[000282][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 13:55:19 GMT From: anilg@cs.tamu.edu (Anil Kumar Reddy Gurijala) To: comp.protocols.tcp-ip Subject: Question on tcp protocol
Hi folks, Under what circumstances a tcp layer packs two different data segments from upperlayer into a single packet? i.e. if I use send(a) and send(b) in two different instructions, is it possible that tcp layer packs both of them in a single packets and sends them to remote host? anil gurijala anilg@cs.tamu.edu
-----------[000283][next][prev][last][first]---------------------------------------------------- Date: Tue, 14 Jun 1994 17:01:49 GMT From: donp@novell.com (don provan) To: comp.protocols.tcp-ip Subject: Re: Question on tcp protocol
In article <2tkcs7$rgu@news.tamu.edu> anilg@cs.tamu.edu (Anil Kumar Reddy Gurijala) writes: > Under what circumstances a tcp layer packs two different data segments > from upperlayer into a single packet? i.e. if I use send(a) and send(b) > in two different instructions, is it possible that tcp layer packs both > of them in a single packets and sends them to remote host? When does TCP ignore send boundaries? Whenever it wants! TCP provides a reliable byte stream of data. While each byte sent will be delivered in order and intact, TCP makes no attempt at all to maintain the original grouping of the bytes. To maintain the grouping, you'll need to have your own mechanism in the application protocol. don provan donp@novell.com
-----------[000284][next][prev][last][first]---------------------------------------------------- Date: Tue, 14 Jun 1994 18:43:13 GMT From: gnn@netcom.com (George Neville-Neil) To: comp.protocols.tcp-ip Subject: Re: Question on tcp protocol
anilg@cs.tamu.edu (Anil Kumar Reddy Gurijala) writes: > Under what circumstances a tcp layer packs two different data segments > from upperlayer into a single packet? i.e. if I use send(a) and send(b) > in two different instructions, is it possible that tcp layer packs both > of them in a single packets and sends them to remote host? If I understand your question correctly you are asking about where the data from a particular call to send(2) on a TCP socket winds up. TCP is a stream protocol and will pack, or segment data, independantly of calls to send. If you want a packet oriented protocol you should look at UDP, or you can place your own makers in the stream of a TCP connection. Hope this helps. Later, George -- gnn@netcom.com Gentlemen, I will not have you fighting in the War Room. --- The President in Dr. Strangelove
-----------[000285][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 19:03:30 GMT From: karthik@informix.com (Karthikeyan Guruswamy) To: comp.os.ms-windows.programmer.win32,comp.protocols.tcp-ip Subject: How does Windows NT work on the internet ?
Hi, This is something I really want to know. How does Windows NT work on the internet ? Can I have two Windows NT machines across the internet and can share resources just like the way I can do it on my local network ? I saw something like NETBIOS encapsulated with TCP/IP during the installation. Does it work ? I am very sure that if it is talking NETBIOS, there is no way the 'packets' can get past the standard routers. Has someone thought about this ? Also, can someone enlighten me about DHCP ? Karthik
-----------[000286][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 19:53:58 GMT From: sklower@oboe.CS.Berkeley.EDU (Keith Sklower) To: comp.protocols.tcp-ip Subject: Re: Multiple IP addrs for same hardware interface?
In article <1994Jun2.034930.24757@relay.nswc.navy.mil>, Chuck Smoko - E81 <csmoko@relay.nswc.navy.mil> wrote: >In article <1994Jun1.135707.10535@cherokee.nsuok.edu> landin@cherokee.nsuok.edu (Mark C. Landin) writes: >> >>So how did you get around it? I'm going to do the hardware shuffle in a >>month or two and would like any helpful anecdotes from people who've >>done it. > >I have some code allows the multiple addresses per interface. >... code (included), but I have ported it Sunos. > I've also done it. Code supporting this has been distributed by Berkeley since NetII. The syntax is ifconfig if0 inet alias <rest of the command line is the same> If you have two IP address from the same subnet as calculated by the netmask on the same interface there is a minor bug in some of the earlier versions in that you have to do a route add host <2nd address> 127.1 to be able to send stuff to that address from the machine itself. Receiving from the outside works. It is also supported in OSF/1.
-----------[000287][next][prev][last][first]---------------------------------------------------- Date: Tue, 14 Jun 1994 21:27:33 GMT From: haggis@netcom.com (John R. Haggis) To: comp.protocols.tcp-ip Subject: Re: TCP ports
In article <CrC9Dw.GsD@pica.army.mil> prodrig@gundam.batdd (Paul) writes: > I'm hoping someone can answer a couple of basic questions, or help me >to get started on the right track by letting me know where some of this >information can be obtained. What I'm trying to do is connect a vax to a >sparc station and use TCP for data transfer. Thank you very much in advance. I read Lance's reply to you, and I'm worried you'll get confused if you're new to this. Bottom line is: Barring any pecularities on the VAX end, it should be pretty easy once you get them networked. Hopefully, you'll be using ULTRIX or some kind of UNIX clone on the VAX. This is the overview: a. get the machines physically networked (cables and any requried boxes). b. get the network drivers running (ifconfig, route, etc.). c. as part of b., make sure you know the IP addresses you assign them. d. "ping" each machine from the other to make sure they're talking. At this point, the machines will be "talking" on TCP/IP. To transfer data, you have two basic choices: A. Use a high level application, like ftp, to transfer the data. B. Write your own software using TCP Sockets. (what Lance was talking about). C. one other: use NFS to mount a drive from one computer on the other. Then you can just copy files. You seem to be leaning toward writing your own software with sockets? (Otherwise, why are you talking about "ports"?) I don't recommend this if you're new to this, unless your application demands automatic data transfer. Let me know. >1. When establishing a TCP connection, how does one determine what the port numbers will be in use on both machines? The ports for standard applications, like FTP, Telnet, etc. are predetermined for Unix systems. For your own custom program, you can choose any arbitrary port number, as long as both sides (sender and receiver) agree on the same one, and it doesn't conflict with any standard port number usage. Look in your manual, and in etc\services or some such file for the standard ports defined on that machine. There should also be something in sockets docmuentation about typical port numbers for use in custom programs. >2. When transfering data between a vax and a sparc station, will the data be transfered in a pre-determined format such as binary or ASCII, or will both users have to determine which format will be used in advance. If you use a high-level application, like ftp, it has settings in it for how to transfer the files' data. If you write your own software, you can use any format you like. TCP/IP just transfers packets of numbers. It doesn't care what they are. Likewise, Sockets (which run just above tcp) don't care what you send; they just send streams of numbers. It's your application that must make some sense out of it. Beware VAX implementation peculiarities of these things. We're still laboring under some backwards, draconian conventions DEC foisted on us in the early days pertaining to 7-bit values here and there... If you're using Unix variants you shouldn't have to worry, though. Have fun. - JohnR (haggis@netcom.com)
-----------[000288][next][prev][last][first]---------------------------------------------------- Date: 15 Jun 1994 09:36:59 -0700 From: rdervan@crl.com (Richard Dervan) To: comp.protocols.tcp-ip Subject: MacTCP problems
I'm having a problem getting the MacTCP that comes with the Macintosh Internet Tour Guide up adn running. Every time I try to enter the IP address, it comes back and tells me that it is an invalid address and that I need to go into the MacTCP control panel and set the IP address. Also, does anyone know where I can pick up a copy of the docs via FTP or someway? Thanks, -Richard -- --------------------------------------------------------------------------- Richard Dervan - VMS System Manager rdervan@crl.com Information America 70007.6230@compuserve.com Atlanta, GA Go Braves! Chop Chop!
-----------[000289][next][prev][last][first]---------------------------------------------------- Date: 14 Jun 1994 22:24:13 GMT From: chris@jbasp.demon.co.uk (Chris Bradshaw) To: comp.protocols.tcp-ip Subject: [Q] Any good books on network routing???
Greetings Netters... I was wondering if anyone reading this could recommend any good books (or free documentation on the internet) which deal with configuring and administrating routing in TCP/IP networks. I already have a few books which deal with the more technical aspects of the various routing protocols (i.e. what each byte of each packet represents etc.). I am really looking for something which shows how to configure routing in different situations using something like gated with the latest protocols and subnetting techniques (i.e. RIPv1, RIPv2, OSPF, multicasting etc......I don't suppose O'Reilly & Assoc. have a 'gated' book on the way?) Any and all replies much appreciated. Thanx in advance. -- Chris Bradshaw ---------------------------------------------------------------------------- JBA Software Products Ltd., | Internet: chris@jbasp.demon.co.uk Eagle House, | Studley, | Voice: (0527) 854525 Warwickshire B80 7EN, | FAX: (0527) 857146 England. | ----------------------------------------------------------------------------
-----------[000290][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Jun 1994 00:44:49 GMT From: atkinson@sundance.itd.nrl.navy.mil (Ran Atkinson) To: comp.security.misc,comp.protocols.tcp-ip Subject: Re: Query: trusted routers
In article <2tk9jp$auh@gabriel.resudox.net> sharris@resudox.net (Sandy Harris) writes: >Are there any packet filtering IP routers evaluated for >interesting security levels, American B's or some other country's >standard? I understand that Advanced Computer Communications Systems (ACC Systems) has a fairly new product named "Stealth" which is targeted at an Orange Book/Red Book B3 level. ACC Systems has indicated that they are submitting it to NCSC for formal evaluation. I'm pretty sure that final evaluation is not yet complete. You might contact them directly for more information. They have an office somewhere near Columbia, Maryland, USA. The product is real -- they showed one in DC late last week at the AFCEA tradeshow. It implements most normal routing protocols. To my knowledge that is the only router designed for formal evaluation under both Orange Book and Red Book criteria. Its also the only B3-targetted router I know about. I would guess that they'll get a fair amount of business if they price it reasonably. Ran atkinson@itd.nrl.navy.mil
-----------[000291][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Jun 1994 09:05:00 -0500 From: Bill.Beers@f240.n379.z1.fidonet.org (Bill Beers) To: comp.protocols.tcp-ip Subject: Re: Is IP source routing a bad idea?
BP> bparker@pilot.njin.net (Bruce Parker) wrote: BP> BP> Bhagwat and Perkins (Mobile and Location-Independent Computing BP> Symposium), Johnson (CMU TR), and Rekhter and Perkins (Internet draft BP> "Loose Source Routing for Mobile Hosts") use LSR to allow mobile hosts BP> to retain the same IP address while moving through the internet. Is there an RFC associated with LSR? While I don't have hosts moving thru THE Internet, I will have pen computers moving from base station to base station. Our current configuration has the base station acting as an IP router. My recommendation based on only having a small number of Pen Computers floating around was to find a base station that would act as a mac bridge capable of filtering out unwanted traffic. However, sounds like LSR, from what's said above, might be an alternative. Does anyone implement LSR commercially yet?
-----------[000292][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Jun 1994 01:39:06 GMT From: marstein@netcom.com (Martin Stein) To: comp.sys.mac.misc,comp.sys.mac.wanted,netcom.software.mac,comp.sys.mac.comm,comp.protocols.tcp-ip Subject: Sun RPC on Mac?
I am looking for a Sun RPC library for the Macintosh OS. Did anyone ever run across something like that? I would appreciate any hints. Thank you Martin (marstein@netcom.com) -- ---------------------------------------- Martin Stein Ixos Software GmbH, Munich, Germany SAP America Inc, Foster City, CA Email: martin.stein@ixos.de marstein@netcom.com 100031.2333@CompuServe.COM
-----------[000293][next][prev][last][first]---------------------------------------------------- Date: 15 Jun 1994 08:56:26 GMT From: charl@pondermatic.ee.up.ac.za (Charl Barnard) To: comp.protocols.tcp-ip Subject: Re: bootp server response times
In article <2tkmsv$1v9@edwin.bga.com> dpm@bga.com (David P. Maynard) writes: Path: inet.up.ac.za!ee.und.ac.za!psgrain!charnel.ecst.csuchico.edu!yeshua.marcam.com!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!gatech!udel!news2.sprintlink.net!news.sprintlink.net!bga.com!bga.com!nobody From: dpm@bga.com (David P. Maynard) Newsgroups: comp.protocols.tcp-ip Date: 14 Jun 1994 11:46:23 -0500 Organization: Real/Time Communications - Bob Gustwick and Associates Lines: 32 References: <CHARL.94Jun14133617@pondermatic.ee.up.ac.za> <2tkbo1$nms@news.iastate.edu> NNTP-Posting-Host: edwin.bga.com Paul J Lustgraaf <grpjl@iastate.edu> wrote: >However, an apparently related problem is that a lot of the DOS/Mac >client software isn't very forgiving of "slow" BOOTP servers. It >seems to be fairly common to fire off a half-dozen requests at >1-second intervals and give up if an "acceptable" reponse isn't >received. Some packages apparently check the sequence number because >they ignore responses from previous requests. That means the response >must come back in under 1 second. (I haven't verified this, but some >clients have logged the behavior.) For a SLIP line, the 1-second >turnaround requirement is pretty marginal. Thanks for the suggestion; unfortunately running bootpd in server mode still doesn't solve the problem. The first request always seems to get lost, and after that, response is ok. -Charl
-----------[000294][next][prev][last][first]---------------------------------------------------- Date: 15 Jun 1994 21:31:59 -0700 From: r_daems@pinyon.libre.com (Robert Daems) To: comp.protocols.tcp-ip Subject: OS/2 TCP/IP and windows ?
I am trying to get Windows to add, access Network files using tcpip. I have installed winsock for tcpip (IBM TCPIP 2.0) and mount several disks on start up. The disks are available under OS/2, but under Windows It doesn't know it has a network. What do I need to do to get the windows to "See" an TCPIP network?
-----------[000295][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Jun 94 18:20:26 -0500 From: Peter Chapman <bankrupt@delphi.com> To: comp.protocols.tcp-ip Subject: Re: Connecting the PC to the Internet
You connected your PC to the Internet, and people can now ftp from your machine? I don't want mere access, I also want to set my PC up as a server. Thanks!
-----------[000296][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Jun 1994 10:12:38 GMT From: ccadda@beluga.upe.ac.za (Daryl Anderson) To: comp.protocols.tcp-ip Subject: Re: BOOTP and NCSA Telnet
In article <2ti41q$l9u@blue.weeg.uiowa.edu> gpalmer@blue.weeg.uiowa.edu (Gary Palmer) writes: >From: gpalmer@blue.weeg.uiowa.edu (Gary Palmer) >Subject: BOOTP and NCSA Telnet >Date: 13 Jun 1994 12:12:26 -0500 >Keywords: BOOTP NCSA TELNET >I am having trouble in getting the myip=BOOTP to work with the latest >release of NCSA Telnet, 2.3.07. >It seems that the FTP client works fine with this parameter, but if >I don't specifiy an exact ip address with myip=, Telnet will eventually >come back with an error that it cannot communicate with a BOOTP >server. >Again, I think I have the server working, because it satisifies FTP, >and it satisifies other TCP/IP software that I've been working with, >like WINSOCK, but NSCA Telnet 2.3.07 it does not. >Has anyone come across this problem? Yes, I had this problem with 2.3.07. I am currently working on the NCSA source. So far I have fixed the BOOTP. It was caused by a buggy implementation of UDP in the NCSA kernel. I rewrote the UDP implementation. There is also a problem connecting to Solaris 2.X hosts. The recognition of fragmented/do not fragment TCP datagrams was buggy. This version is now working successfully on our campus. I have added LPD, fixed RCP and FTP. There are other subtle bugs in the kernel which I am currently tuning. I do not read this news group regularly, so if you want further correspondance please email me. Regards Daryl +--------------------------------------------------------------------+ Daryl Anderson Internet: ccadda@beluga.upe.ac.za Network Consultant Tel: +27 41 5042321 University of Port Elizabeth Fax: +27 41 5042574 "A program that works first time contains a more subtle bug" - DLS +--------------------------------------------------------------------+
-----------[000297][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Jun 1994 14:19:40 GMT From: richlove@netcom.com (Rich Love) To: comp.protocols.tcp-ip Subject: Mac Plus and TCP
Several people have reported problems trying to make a Mac Plus work with MacTCP. Has anyone out there had this problem and if so is there a solution to it? Here are the posts I copied from the Mac Communications newsgroup: > In Article <2tagab$amp@io.qcc.sk.ca>, marc@qcc.sk.ca (Marc St-Jean) wrote: > >I have MacTCP installed on a number of machines (including a Classic > >running 7.1) and everything runs well. > > > >However I can't get it to work with a Mac Plus running 6.0.7. The > >manual states that the minimum requirements should be a Plus with > >6.0.5. I've tried both Network Installers 1.3.2 and 1.4.3. I've tried > >reinstalling the system, etc. > > > >I should include some details: > >- we are running MacTCP over LocalTalk > >- the MacIP gateway is in another zone > > > >Has any run into this situation and if so what is the fix? (Other than > >throwing away the Plus :-) > > ========================================== > I have a customer in the Seattle area with the same problem and would also > like an answer to this question. The TCP/IP manual says it is supposed to > work with a Mac Plus. ----------------------------- I have been having the similar problems. I have tried two or three versions of TCP/IP as well as diffrent versions of AppleTalk. All to no avail. The TCP/IP driver seems to boot up fine but when I try to ping any other machine on my net I get timeout errors. I am guessing that there may specific design flaws with a Mac Plus that will prevent it from running TCP/IP, even though the manual says it should work. I am attempting to connect the plus over AppleTalk to a Shiva fastPath and then to my IP gateway. Nothing I have tried works. Any Help would be appreciated. -------------------------------------------------------------------------- -- Rich Love Carnation Software, Inc. | MacToPic and SBMac - Macintosh to Host connectivity and file transfer | | for PICK, uniVerse, unix, System Builder and other host systems. | | Viewpoint, Wyse 50, VT101 and Prism emulations included. | | Demo available for download at ftp.netcom.com in pub/carnation | | Home page at file://ftp.netcom.com/pub/carnation/HT.Carn.Home.html | | Phone (206) 333-4288 Internet: richlove@netcom.com |
-----------[000298][next][prev][last][first]---------------------------------------------------- Date: 15 Jun 1994 15:31:47 GMT From: kannan@cs.ualberta.ca (Kannan Thiruvengadam) To: comp.protocols.tcp-ip Subject: RTP Code Available ?
Hi, RTP (Realtime Transport Protocol) is (as the name suggests) meant for Realtime applications. It works on Multicast IP. If any of you know any way of getting hold of the code (which must have developed by IETF AVT, please post/mail the contact address. Thanks. - Kannan -- 615, General Services Building, University of Alberta, Edmonton CANADA T6G 2H1 --------------------------------------------------------------------------- What is life ? An opportunity to live.
-----------[000299][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Jun 1994 16:06:20 GMT From: art@acc.com (Art Berggreen) To: comp.protocols.tcp-ip Subject: Re: Question on tcp protocol
In article <2tkcs7$rgu@news.tamu.edu> anilg@cs.tamu.edu (Anil Kumar Reddy Gurijala) writes: > Under what circumstances a tcp layer packs two different data segments > from upperlayer into a single packet? i.e. if I use send(a) and send(b) > in two different instructions, is it possible that tcp layer packs both > of them in a single packets and sends them to remote host? Sure, if send(a) is smaller than the current TCP segment size then some, or all, of the data in send(b) could be sent in the same segment as data from send(a). This is likely to happen if the TCP window is closed when the two send()s are done. TCP is a BYTE STREAM protocol which makes no guarantees about the relationship of user buffer boudaries and what is in the TCP segments. The send() just copies the data into a kernel buffer. If the TCP window is open, the data is likely to be sent immediately. If the TCP window is closed, the data is held waiting for the window to reopen. If send(b) occurs while data from send(a) is still pending, the new data is just added to the kernel buffer. Eventually, the kernel would block the send() system call if the kernel buffer allotment is filled. Conversly, recv() will attempt to copy data from the kernel's receive buffer to the user's buffer. If less data is available than the users buffer size, the recv() can complete indicating a partial buffer. Where in the data stream this recv() completed may not have any relationship to the send()s at the other end. Hope this helps, Art
-----------[000300][next][prev][last][first]---------------------------------------------------- Date: Wed, 15 Jun 1994 16:10:26 GMT From: edleslie@elearn.edu.yorku.ca (Ed Leslie) To: comp.protocols.tcp-ip Subject: Re: Mac Plus and TCP
Rich Love (richlove@netcom.com) wrote: : Several people have reported problems trying to make a Mac Plus work with : MacTCP. Has anyone out there had this problem and if so is there a solution : to it? A shot in the dark: is the Mac PLUS one of the ones which does not have the capability of hardware handshake because DTR does not come out to the modem plug? There are several Macs like that, and if you are running MacTCP you are *very* likely using a high speed modem with data compression and are configured for hardware handshake. Did I hit anything? :-) Ed
-----------[000301][next][prev][last][first]---------------------------------------------------- Date: 15 Jun 1994 09:38:19 +0400 From: Mark Orlov <mark@mcs.spb.su> To: comp.protocols.tcp-ip Subject: [Q]: Can't send mail via SMTP
1) UNIX box with SVR4 can't send mail via SMTP.
After /etc/rc2.d/S88smtpd run the SMTP demon is created with normal
Helohost:
smtpd -H node.domain
But in the /var/spool/smtpq/LOG file the log information is
smtpd trasport <tcp> opened on fd <5> address <0.0.0.0.0.25>
Netstat -a gives
*.smtp LISTEN
Machine receives mail OK, but can't send it. In the LOG file the lines
are
smtp Can't allocate for client: System error:
And lines in /var/spool/smtpq/*/E.* are
Invalid argument
All other TCP/IP based applications work correctly. DNS is running.
2) Another UNIX box with the same configuration works fine.
LOG file contains
smtpd transport <tcp> opened on fd <5> address <193.125.130.35.0.25>
Netstat -a gives
nodename.smtpd LISTEN
When the receiver is down the LOG file contains
smtp t_connect failed: An event requires attention
What can be done to fix the problems in the first case?
--
Best Regards,
Mark Orlov,
ICL / Marine Computer Systems JV Co.
St.Petersburg, Russia
Voice: +7 (812) 5683952
X.400: (ICL OfficePower) M.Orlov BRA0104
-----------[000302][next][prev][last][first]---------------------------------------------------- Date: 15 Jun 1994 16:23:54 GMT From: vince@dropzone.vti.com (Vince Fleming) To: comp.protocols.tcp-ip,comp.sys.ncr Subject: Re: How to tear down a TCP over X.25 connection?
Nigel Harwood (nigel@coles.com.au) wrote: : Questions: (about X.25) : 1/ Is there a way for the host/remote end to tear down the connection after : completion? : 2/ Is there a way to cause the TCP/IP timeout to be something more reasonable : for my circumstances such as 10 seconds. The TCP/IP waits a min to allow any other traffic to pick up. The overhead in creating the X.25 connection is "sufficient" to keep it up a while. Are you running X.25 on the 3450 or are you using a Router? The cisco routers allow you to set this value (if I remember correctly) -Vince
-----------[000303][next][prev][last][first]---------------------------------------------------- Date: 15 Jun 1994 17:06:53 GMT From: ove@yoyo.neu.sgi.com (Ove Hansen) To: comp.protocols.tcp-ip,comp.sys.ibm.pc.hardware.comm,comp.os.linux.help Subject: X.25 to IP or directly into PC running Linux
I'm looking for a protocol translator or anything else which will allow people to connect to a LAN or directly to a PC running Linux, over X.25. Does anyone know of any cheap-ish protocol translators, or X.25 cards for the PC, with either a Linux driver or DOS packet driver? Thanks in advance, -- Ove Hansen
-----------[000304][next][prev][last][first]---------------------------------------------------- Date: 15 Jun 1994 18:53:10 GMT From: barmar@think.com (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Stop me before I kill again (TCP vs UDP)
In article <2ta4he$o3v@crchh81b.bnr.ca> dawkins@bnr.ca writes: >What I said: "If you're going to keep the same application-level >interface, which is connectionless, you might as well use UDP." ... > The applications already run timers and sequence numbers, > because of the connectionless interface to the MUX software. Is there a way to configure the timers? When running over a reliable transport you can set high timeouts, so retransmissions usually won't occur. The sequence numbers can stay in -- they'll just be redundant overhead. > The developers planned to MUX all conversations over a single > TCP connection, if they used TCP. I was concerned about > applications which sent large numbers of packets back-to-back > causing other applications sending relatively time-critical > "query/response" exchanges to be flow controlled. If the receiver can't keep up with the data, you're likely to get packet drops with UDP, so the application layer would have retransmitted anyway, and your "time critical" packets wouldn't have arrived in a timely fashion. Consider that your raw interface driver performs essentially the same function as the MUX server. As long as the MUX forwards the data to the application processes quickly, you shouldn't have much backlog. > The classic "large number of clients per service" scenerio > applies. I did not want to support, potentially, hundreds of > clients using TCP for (most often)