|
|
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]---------------------------------------------------- Dat