|
|
ARCHIVE: TCP-IP Distribution List - Archives (1993)
DOCUMENT: TCP-IP Distribution List for October 1993 (281 messages, 145762 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1993/10.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 Oct 1993 00:57:19 GMT From: [email protected] (Henry Choy) To: comp.protocols.tcp-ip Subject: HELP! tcpdump is not giving me data...
Let's suppose that I have tcpdump running in promiscuous mode and
giving unfiltered output. No filter restriction is specified.
In that case when I do something like ftp I should get some tcpdump
output pertaining to the ftp, right? I don't get a flicker. So can
someone tell me what tcpdump needs to get started? I'm not sure
what the defaults are. The man page is really sketchy.
When I quit tcpdump it says something like 350 packets (maybe with
some discards). I don't see the headers of all 350 packets though.
The number of discards doesn't account for what I don't see. How
does tcpdump decide what to output? and what not to output?
Another question is if I want tcpdump to get the ftp packets, what
parameters do I set? The man page says something about "port ftp".
I don't know what that means. What does "port" have to do with
"ftp"?
--
Henry Choy
[email protected]
Anything worth doing is worth overdoing. - R. Heinlein
is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield
-----------[000001][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Oct 1993 01:12:22 GMT From: [email protected] (Doug Rudoff) To: comp.protocols.tcp-ip,comp.sys.sun.misc,alt.sys.sun Subject: How do I send a raw IP packet on a Sun (socket? /dev/nit?)
I want to do something very simple: send a raw IP packet out on the Internet. I have a Sparcstation10 running SunOS 4.1.3. I'm not having much luck. I have an IP packet received via radio from a mobile computer. I have a host that acts as a gateway to the Internet and passes the IP packet to our Internet provider. The IP packet is correct when received. The problem is that our host substitutes its IP address for the mobile IP address (as viewed while running etherfind). However, the packet type (ICMP, telnet, etc.) remains as it shoud be. It's as if our host looks at the IP packet and says, "hold it, the destination address says it's not from me. But I'm sending it, so I'll change it to my address." This means that no response from the Internet can be forwarded to the mobile. I open the socket with socket(AF_INET, SOCK_RAW, IPPROTO_RAW) and use a sendto() to forward the packet. Since I'm having problems I'm looking into using NIT. I have source for receiving on nit, but not for sending. The manual pages leave much to be desired. So, any advice and/or source code samples out there that would help me out? Thanks. -- ////////////////////////////////////////////////////////////////////////// Doug Rudoff Motorola, Seattle [email protected] \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
-----------[000002][next][prev][last][first]---------------------------------------------------- Date: 30 Sep 93 12:58:09 NZDT From: [email protected] To: comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc,comp.os.vms Subject: Anybody use PC Route???
Hello, We currently run Multinet TCP/IP and have a connection to the Internet VIA PC Route. PC Route is a package that will run on a PC and do TCP/IP Routing across different interfaces including ethernet cards and the serial port for slip. Our slip connection currently runs at 9k6 and I am looking to upgrade it to perhaps 48k. My Question. Does anybody out there use PC Route?? Has anyone tried to use it at speeds higher than 9k6?? Please email any responses as due to the speed of our link news is about three days behind at the moment. I will post a summary. Thanks, Ken. -- Southpower, Phone: (64)(03) 363-9527 Private Bag, Fax: (64)(03) 363-9816 Christchurch, Internet: [email protected] New Zealand. PSI: 0530130010083::galaxy::fowler
-----------[000003][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 1993 03:02:31 GMT From: Gunnar Helliesen <[email protected]> To: comp.protocols.tcp-ip Subject: Can I do this with a class C network?
Hi, I'm sorry if this is a trivial question to you net-gurus, but here goes: I'd like to set up a SLIP connection between the office and home over a leased line. We don't have all that many addresses, so I'll have to use them sparingly. On the ethernet at work we use one C nett: x.y.105.0 (no subnetting). On this network we have a default gateway/router that connects us to the rest of the world. This gateway has no spare ports, so I'll have to use a VAX(!) on the ethernet as my gateway home. Can I split up a second class C network (using netmask 255.255.255.240) and use the first subnet for the line home: x.y.106.17 (SLIP at work) <--> x.y.106.18 (SLIP at home) *and* use the second subnet (x.y.106.33 - x.y.106.46) for the machines on my ethernet at home? Will the routing software (BTW, which should I use? Static or gated?) see this as two networks (x.y.106.16 and x.y.106.32) and figure out the routing between the nets? I *have* tried to set this up, but couldn't get it to work. The gateways at both ends are VAXen running VMS and TCP/IP, with one ethernet interface and one SLIP interface each. I tried to use gated for routing with simple "rip yes ;" statements in gated.conf (in addition I had to use an "interface le0 passive ;" statement at home in order to keep gated from declaring the ethernet interface down). If this is supposed to work, what happens when someone else wants a line home? Can she or he use the next two subnets in the same fashion as long as they are connected to a second SLIP interface on the same gateway at work? E.g. networks x.y.106.48 (office <--> home) and x.y.106.64 (at home). Or do we really need to use four whole class C networks to get us both up and running? Again, I'm sorry if this is a FAQ or in an RFC somewhere. If so, please point me in the right direction... -- Gunnar -------------------------------------------------------------------------- > | / ___ / ____/ Gunnar Helliesen > > | / / / / / Support/Tech. Manager O > / _/ / ___ / ___ / MBS Fjerndata AS, Bergen, Norway > > / / / / / Voice: +4755343800 FAX: +4755345690 > _/ _/ ______/ _____/ email: [email protected] -------------------------------------------------------------------------- "The reason the universe is so hard to comprehend is that there is nothing to compare it with" -- Douglas Adams --------------------------------------------------------------------------
-----------[000004][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Oct 1993 03:55:47 GMT From: [email protected] (Bryan E. Miller) To: comp.protocols.tcp-ip Subject: TCP/IP over VSAT
Has anyone out there successfully (or unsuccessfully) attempted running IP-based applications over VSAT technology? If so, could you briefly describe your setup and application. Thanks, Bryan
-----------[000005][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 1993 04:32:15 GMT From: [email protected] (Jerry W. Segers) To: comp.dcom.cell-relay,comp.protocols.tcp-ip Subject: Re: New IP protocol?
In article <[email protected]> [email protected] (Dale R. Worley) writes: > It seems that there are several sorts of data streams like real-time > video and audio that have the properties: > - tight timing requirements > - resistance to loss of individual packets ... other stuff deleted I have worked in data communication for a long time, but I am a relatively new to the field of video compression so perhaps the following question is somewhat naive. If so please be kind with your replies and I will quietly go away. Are these two <requirements> for <real time> video as real as Dale and many in the telephony industry seem to believe? My understanding is that any real time video over a network will be compressed in some way, at least to the extent needed to remove the redundant information (e.g. MPEG). I also understand that current compressors are required by current telephony standards to emit constant output streams. Thus each compressor will use a relatively large frame buffer that is filled from the output of the compression process then emptied into the communication path at a constant rate. Is it not reasonable to change the approach when using a transport method like IP that has a variable transmission rate? For example has there been any work done along the lines of moving the buffer to the other end of the path. That is, send the variable output from the compressor directly to the network and collect it in a buffer at the receiving end. If the data arrives too late or is lost, the buffer will empty but the display software can repeat the last frame thus causing the display to stutter then jump but the picture quality will not degrade. The same argument would seem to apply to audio as well. Instead of duplicating the output on buffer empty just output silence. The amount of jumpiness or silence could be controlled by the user at the expense of the output frame rate or by adding bandwidth thus increasing circuit reliability. It seems to me that we have been using this plan for text transmission with great success. If the characters from a Telnet session arrive too slow or sporadically for the receiver, the options are put up with the problem or secure a faster connection. Have I missed something or are the folks like Dale right for requiring a reliable data path? ************************************** Jerry W. Segers Director Regents Telecommunications and Networking P.O. Box 444 Marietta, GA 30061 Phone: 404-423-6860 Fax: 404-423-6868 Internet:[email protected] **************************************
-----------[000006][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Oct 1993 05:37:06 GMT From: [email protected] (Tom Fitzgerald) To: comp.dcom.sys.cisco,comp.protocols.tcp-ip Subject: Host routes on Cisco?
Do Ciscos support host-routes at all? I've been doing some experiments trying to short-cut paths for multihomed hosts, and it appears that Ciscos ignore the host part of any route, whether it's received via RIP or given as a static route. Has anyone managed to get this working? Or, is this a to-be-supported feature? Thanks for any info. -- Tom Fitzgerald Wang Labs, Lowell MA, USA [email protected] 1-508-967-5278
-----------[000007][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Oct 1993 09:35:12 +0000 From: [email protected] (Paul Rossington) To: comp.protocols.tcp-ip Subject: None (mail relay)
Hi,
can someone point me to some example code for using non-blocking sockets?
Thanks in advance.
Paul
--
=============================================================================
|
Paul Rossington, | "Sometimes I think the surest sign that
Datastream International, London | intelligent life exists elsewhere in the
[email protected] | Universe is the fact that none of it has
[email protected] | tried to contact us" - Calvin to Hobbes
|
=============================================================================
-----------[000008][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 93 15:51:18 CDT From: [email protected] To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Need help choosing E-net card and software
I have a student that needs to write a program to send/receive data over the Internet. His PC is going to be hooked to ethernet. His program will have the data. He needs to write software to encapsulate the data into IP packets and transmit them to a remote site. He'll then, of course, need to be able to receive data from the remote site in a like manner. I need a recommendation for an ethernet card and card contol software. He'd like to write C routines to control the ethernet card driver... maybe even just issue calls to a card driver that will handle all the TCP/IP overhead. Please email replies since I don't read these groups regularly. Thanks. Michael McGinnis Internet: [email protected] Computer Center Bitnet: [email protected] University of Kansas Voice: (913)864-0413 Lawrence, KS 66045 FAX: (913)864-0485 Rust never sleeps.
-----------[000009][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Oct 1993 16:23:56 From: [email protected] (Kevin Kahn) To: comp.dcom.cell-relay,comp.protocols.tcp-ip Subject: Re: New IP protocol?
In article <[email protected]> [email protected] (Jon Crowcroft) writes: >a lot of work on next generation IP includes concepts of link sharing (a form of>VPN) >as well as supporting traffic which must needs be treated differently, in the >context >of starting with bursty (traffic that needs big buffers in switches) and adding >less bursty (CBR video, or voice) (not to get into a debate about whether VBR >video is bursty...) >this is in contrast to the bulk of published work on aTM which starts with >supporting policed (leaky bucket sources) and has only recently added some >work on adding really bursty sources... The Traffic Management WG at ATM Forum seems to have finally come to grips with officially discussing this issue. Although there seems to be a strong contingent of Telco types that still focus their attention on rate controlled VCs, there is now an official work item to address a service (coined Available Bit Rate following Constant and Variable Bit Rate) that would have low cell loss probability but potentially long delays. The notion is to define a service and mechanisms to allow the network to tell the application on a continuing basis what bandwidth is "available". This is intentionally worded a bit strangely to avoid a priori prejudicing the mechanisms to accomplish the goal. There are flow control advocates, BECN types, FECN types, and folks who think hybrid solutions will be needed. At least the topic is now on the table and hopefully the merging of the various camps that Jon hopes for can happen. Kevin Kahn Intel Architecture Labs
-----------[000010][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Oct 1993 12:52:20 GMT From: [email protected] (Freedman) To: comp.protocols.tcp-ip Subject: where is "Where are You" ?
I have a network consisting of Suns running 4.1.2 and 4.1.3. If I wish
rlogin from a .3 sun to a .2 sun or vice verso everything works fine ->
my rhost file(s) are fine. However if I try to rcp where the .3 sun is a
server ie the rcp is issued on the .2 machine) I get a "where are you" and the command exits. It works fine in the other direction. If I do a rsh from a .2 machine to a .3 machine I still get the "where are you" but the command will
execute. It works fine in the other direction. I have RTFM'ed but maybe in the
wromg place. This is obviously some sort of configuration problem. What is
happening.
Jerry Freedman,Jr
-----------[000011][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 93 13:53:28 GMT From: [email protected] (Mike Hartman) To: comp.protocols.tcp-ip Subject: Re: FAQ ?
>Sorry to post this here. Just want to make all clear for the new ones. > >In article <[email protected]>, Jim Schenk <[email protected]> wrote: >>Is there a FAQ for this list? >> > >Yes, of course, almost every important group has a FAQ. >It is posted here (at regular intervals). >Subscribe to news.answers and you'll get all the FAQ you've (n)ever >wanted to know about. Well, I've never seen an FAQ posted on comp.protocols.tcp-ip, and I don't consider myself a ``new one'' (I've been reading this group the last 3 years). Where is the FAQ ?? -- Michael Hartman | e-mail: [email protected] Software Engineer | phone: (215) 277-8300 Human Designed Systems, Inc. | FAX: (215) 275-5739 421 Feheley Drive | King of Prussia, PA 19406 (USA) | ----------------------------------------------------------------
-----------[000012][next][prev][last][first]---------------------------------------------------- Date: Fri, 01 Oct 93 17:25:51 GMT From: [email protected] (Russell Nelson) To: comp.protocols.tcp-ip Subject: Text Descriptions with FTP's "ls" command
In article <[email protected]> [email protected] writes:
PS, I really love how programs like NcFTP send junk like:
NLST -FC file
assuming that all (unix) LIST/NLSTs are ls-based... (*sigh*)
That's why the FTP protocol needs a new XLST command, which is
guaranteed to return information in a parsable format. The obvious
choice is the output of "/bin/ls -lg". That makes implementing XLST
just a matter of making an alias for NLST.
-russ <[email protected]> What canst *thou* say?
Crynwr Software Crynwr Software sells packet driver support.
11 Grant St. 315-268-1925 Voice | LPF member - ask me about
Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
-----------[000013][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 1993 18:23:04 GMT From: [email protected] To: comp.protocols.tcp-ip Subject: Enabling TCP to output state/debug info
Hello, I am currently trying to teach myself how TCP works. I noticed there exists a tcp_debug module that allows for some TCP state information to be output. How do I get TCP to output the debug infomation? I am assuming someone out there has done it because the tcp_debug function exists! ;^} I am running a SUN3 w/SunOS 4.1.1. I also have the TCP source. Thanks in advance! Alan W. Johnson SRI International
-----------[000014][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Oct 1993 19:27:43 GMT From: [email protected] (Craig Partridge) To: comp.protocols.tcp-ip Subject: re: Design of parallel TCP. Is it possible ?
> I'm wondering if TCP protocol can be parallelized to make the > processing of the protocol more effective. Leaving aside the notion of what `effective' is, the answer is yes, TCP can be parallelized, and in ways that make at least some good use of the multiple processors. Note that there are several ways to do this, most of which don't work well. Many folks try to do different functions (e.g., checksum, sequence number, etc) in different processors. That's typically a losing approach, because the cost of coordinating among the processors far exceeds the number of instructions required to do the TCP processing. A more winning approach appears to be to have several processors each capable of doing all the TCP processing for a segment, and assigning incoming segments round-robin among the processors. (See, for example, Bjorkman and Gunningberg's paper in Proceedings of ACM SIGCOMM '93). Craig
-----------[000015][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Oct 1993 20:54:41 GMT From: [email protected] (John Hascall) To: comp.protocols.tcp-ip Subject: Re: Text Descriptions with FTP's "ls" command
[email protected] (Russell Nelson) writes: }In article <[email protected]> [email protected] writes: } } PS, I really love how programs like NcFTP send junk like: } } NLST -FC file } } assuming that all (unix) LIST/NLSTs are ls-based... (*sigh*) } }That's why the FTP protocol needs a new XLST command, which is }guaranteed to return information in a parsable format. The obvious }choice is the output of "/bin/ls -lg". That makes implementing XLST }just a matter of making an alias for NLST. ... all the world's Unix disease again ... John -- John Hascall ``An ill-chosen word is the fool's messenger.'' Systems Software Engineer Project Vincent Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
-----------[000016][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 93 21:24:38 GMT From: [email protected] (Randy Turner) To: comp.protocols.tcp-ip Subject: Re: Design of parallel TCP. Is it possible ?
[email protected] (Craig Partridge) writes: >> I'm wondering if TCP protocol can be parallelized to make the >> processing of the protocol more effective. >Leaving aside the notion of what `effective' is, the answer is yes, TCP >can be parallelized, and in ways that make at least some good use of the >multiple processors. > >Note that there are several ways to do this, most of which don't work well. >Many folks try to do different functions (e.g., checksum, sequence number, >etc) in different processors. That's typically a losing approach, because >the cost of coordinating among the processors far exceeds the number of >instructions required to do the TCP processing. > >A more winning approach appears to be to have several processors each capable >of doing all the TCP processing for a segment, and assigning incoming >segments round-robin among the processors. (See, for example, Bjorkman >and Gunningberg's paper in Proceedings of ACM SIGCOMM '93). >Craig I would think the TCP checksum would probably be the only good candidate for parallelizing (?) I'm assuming that multi- threaded STREAMS implementations would not be considered in this case since I think the person asking the question meant parallelizing single connection processing through TCP.... Randy -- ----------------------------------------------------------------------------- Randy Turner QMS, Inc. [email protected]
-----------[000017][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 93 21:36:50 GMT From: [email protected] (Randy Turner) To: comp.protocols.tcp-ip Subject: audio conferencing software - mbone
I am looking for the software that allows internet-wide audio conferencing between <n> numbered audio-capable workstations...Recently I heard that it was on one of the machines in the lbl.gov domain but I forgot which one. Also, I believe I will also need the SunOS 4.1 kernel patches to support IP Multicast. Does anyone know where these patches are and possibly provide some quick procedure for building the kernel with these new changes ? Thanks! Randy -- ----------------------------------------------------------------------------- Randy Turner QMS, Inc. [email protected]
-----------[000018][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Oct 1993 21:53:53 GMT From: [email protected] (Najam Ahmad) To: comp.protocols.tcp-ip Subject: Looking for IP conformance tests
Hi, I am looking for scripts/applications for IP conformance/performance testing of a router. I need something that can run under DOS, UNIX, or Domain OS. Could anyone who has any information about such applications mail me the information. Thanx in advance! Best Regards, Najam ------------------------------------------------------------------------------ Najam Ahmad Email: [email protected] Netrix Corporation Phone: (703) 793-1001 13595 Dulles Technology Drive Fax: (703) 713-3805 Herndon, VA 22071 ------------------------------------------------------------------------------
-----------[000019][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 1993 23:29:02 GMT From: [email protected] (Henry Choy) To: comp.protocols.tcp-ip Subject: REQUEST: tcpdump raw packet output format
There's a -w option for tcpdump to write the raw packets to a file.
Does anyone know the format of this write?
I look at the resulting file and it's binary! I can't read it.
For instance when I use tcpdump -r on the binary, tcpdump gives the
time stamp and all sorts of information. Well, how the heck does
tcpdump figure out this from the file???????????
I can't see the time stamp (example time stamp 17:17:41.634657) in the
file. However, if I use od -a on the file every once in a while
there's about 5 or 6 bytes of coherent information nested in
all kinds of crap.
--
Henry Choy
[email protected]
Anything worth doing is worth overdoing. - R. Heinlein
is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield
-----------[000020][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 1993 23:47:33 GMT From: [email protected] (Henry Choy) To: comp.protocols.tcp-ip Subject: HELP! Where do ftp transfers go?
I'm trying to use tcpdump to read the network traffic due to ftp
activity. When the ftp starts, tcpdump spits out some info, but
tcpdump stops after that even though I'm transferring millions of
bytes. Does this mean the information in the file cannot be seen
with tcpdump?
Let's say that tcpdump picks up headers only. Does this mean the
file transfer occurs with only a constant number of initiating
conversation packets and a terminating packet? This is inconceivable
when I'm dealing with a 1 Meg file (maybe).
Another explanation which may be true is many packets are used
to transfer my file, but these files are not ftp packets. In that
case, I don't know what an ftp packet is and I'd appreciate someone
telling me all the types of packets ftp uses during a transfer!!!
--
Henry Choy
[email protected]
Anything worth doing is worth overdoing. - R. Heinlein
is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield
-----------[000021][next][prev][last][first]---------------------------------------------------- Date: Fri, 1 Oct 1993 23:59:49 GMT From: [email protected] To: comp.protocols.tcp-ip Subject: OpenView Product Requirements
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/_/_/ _/ _/
_/ _/ _/ _/ _/
_/ _/ _/_/_/ _/_/ _/ _/ _/ _/ _/_/ _/ _/
_/ _/ _/ _/ _/ _/ _/_/ _/ _/ _/ _/ _/ _/ _/ _/
_/ _/ _/ _/ _/_/_/_/ _/ _/ _/ _/ _/ _/ _/_/_/_/ _/ _/ _/
_/ _/ _/ _/ _/ _/ _/_/ _/_/ _/ _/ _/_/_/_/
_/_/_/ _/_/_/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/ _/
_/
_/ _/_/_/_/_/
_/ _/
_/ _/_/ _/_/_/ _/ _/ _/ _/
_/_/_/ _/ _/ _/ _/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/ _/ _/ _/ _/ _/ _/ _/
_/ _/_/_/ _/ _/_/_/ _/ _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Dear Users/Developers:
Tell the OpenView Forum what Issues need to be addressed by specific
vendor(s) and topic for the upcoming User/Developer conference scheduled in
Oct/Nov in Dallas.
We want to tell HP & HP OpenView Premier partners the types of requirements,
comments/suggestion, Hot Issues, etc that will need to be addressed by the
speakers at the conference. (We want the correct people present at the
conference to answer the MAIL!!!)
We want to make sure that speakers come prepared to address issues most
important to YOU!! With that in mind, would you please:
List any issues that you would most like to see addressed at the
conference, including issues related to one or more of the following:
- OpenView strategy
- Product-specific features/functions and evolution
- Platform technologies
- Others, such as standards bodies involvement,
partnerships, whatever...
We need your suggestions for enhancements to the HP OpenView Microsoft
Windows and Unix product line as well as the premier partners product
line. Send the Forum as many Email requirements/suggestions/issues you
want TODAY!!!!.
Remember the Key for this First year's OpenView Forum is INTEGRATION of
Vendor Solutions to the OpenView Framework!!!
At the Forum we will also collect requirements so they can also be
categorize, and VOTE on these on the seconds day of the conference.
Please don't want until the day of the conference to submit your input!!
YOU NEED TO GET THE INFORMATION TO THE OPENVIEW FORUM VIA EMAIL ASAP!!!
Please help us in getting the requirements documented and so we can have
this information available On-Line for review at the OpenView Forum conference.
Below is a sample form, which you can use to docuement your input to the Forum!
VENDOR:________________________________ Issue:__________________________
(Evolution, Features, Integration,
Design, Cost, etc)
PRODUCT:_______________________________ Rating:_________________________
(HOT, WARM, Cann't Live without,
etc)
Description:____________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Suggested Enhancement:__________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
Return your replies to:
[email protected]
Thanks Frank Belland
VP Technical Operations
-----------[000022][next][prev][last][first]---------------------------------------------------- Date: 1 Oct 93 11:50:07 NZDT From: [email protected] To: comp.protocols.tcp-ip Subject: Question on SLIP
Hello, I have a simple question about the SLIP protocol. I want to know if it can be used across a Synch pair of modems as well as Async. Sorry if this is a stupid question. Otherwise can anyone point me towards an RFC for slip. Please email any responses as due to the speed of our link news is about three days behind at the moment. Thanks, Ken. -- Southpower, Phone: (64)(03) 363-9527 Private Bag, Fax: (64)(03) 363-9816 Christchurch, Internet: [email protected] New Zealand. PSI: 0530130010083::galaxy::fowler
-----------[000023][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 Oct 1993 01:23:41 GMT From: [email protected] (Tom Fitzgerald) To: comp.protocols.tcp-ip Subject: Re: Specifying IP
[email protected] ( Chris Rohrer) writes: > Never having tried to hook up two IP devices or (even worse) networks > together I need to know just how you go about specifying everything you > have to do to have a set of rules for a well-behaved network. > Can I just say "Oh, > we'll just put in an Ethernet and use the TCP/IP protocol suite over it" and > use all the "default" settings out of the box, as it were? Yes, absolutely. You sound doubtful, but almost all the decisions you could make in a configuration like this have been taken out of your hands and put in the software, which figures out what to do based on person- millenia of painfully gained experience. While there are some things you can adjust (you can lower MTU, though you can almost never raise it, etc), you should do this only after you get an intimate knowledge of how the net works in its normal, out-of-box setup. This is something you can only learn with experience, and the default nearly always works fine. > MTU size > Version number > Use of other header fields > Use of optional fields > Use of address resolution mechanism(s) All these are defaulted to the right values by software (MTU depends on the hardware, Version=4, address resolution=ARP) or vary by application (optional header fields in ping -R or traceroute). They're not meant to be messed with at install time. > Like if I were to write an "interface specification" to my IP network, what > items would I absolutely have to specify (ignoring for the moment the > actual applications and their requirements...)? I'd recommend you put these items in your "interface specification": - Always use an officially assigned network number from the NIC; never, never make up a network number even for "temporary" use. - If you're installing SMTP, the same applies to the domain name. - If you have more than a dozen or so systems, use DNS or NIS. If you have systems that are maintained by more than one organization (or by two or more individuals who are not co-workers), use DNS. - If you use NFS or SMTP, also use a time-synchronization protocol like ntp (recommended) or timed (not recommended, but sometimes necessary) or both. Even if you don't use NFS or SMTP, this is worth considering. - If you have an external network link, or even a single dialin line, or systems in publicly accessible areas, set things up to be secure and never forget about security. These might not be what you were asking for, and some people in your position won't like to think about these things (because they involve extra work and aren't as satisfying as a pronouncement of "Thou shalt use an initial TTL of 255"), but they really are the things that will burn you if you don't do them right from the beginning. Good luck. -- Tom Fitzgerald Wang Labs, Lowell MA, USA [email protected] 1-508-967-5278
-----------[000024][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 Oct 93 03:38:20 GMT From: [email protected] (Stuart Friedberg) To: comp.protocols.tcp-ip Subject: Re: Design of parallel TCP. Is it possible ?
In article <[email protected]> [email protected] (Craig Partridge) writes: >A more winning approach appears to be to have several processors each capable >of doing all the TCP processing for a segment, and assigning incoming >segments round-robin among the processors. (See, for example, Bjorkman >and Gunningberg's paper in Proceedings of ACM SIGCOMM '93). If the vendor-specificity will be excused, Sequent's PTX operating system features fully symmetric multiprocessing, and our TCP and other comms products are all STREAMS based. As a result, you can get real concurrency at various levels in the protocol stack via STREAMS service procedures (doesn't happen that often), as well as getting per-segment multiprocessing for free via interrupt handling symmetrically shared among the processors (happens all the time). With some recent changes that will ship in our next release (perhaps the current release as well, not sure), we *efficiently* support over 2000 active TCP connections on our commercial systems (some customers have these modifications already). Mind you, that's 2000 connections in an environment where move-to-first optimizations of BSD-style pcb lookups do *not* buy you very much. There have been papers on this issue ... Stu Friedberg ([email protected])
-----------[000025][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 1993 04:16:39 GMT From: [email protected] (Sudheer Dharanikota) To: comp.protocols.tcp-ip Subject: Sharing ACE..
Hai,
I am trying to access the ARP cache entry (ace) from
IP. Can someone who is familiar with the source code of IP
and ARP help me where to look for and how to access this
information. I am working on solaris 2.1 OS.
Thank you,
sudheer.
-----------[000026][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 Oct 1993 07:50:03 +0000 From: [email protected] (Phil Royse) To: comp.protocols.tcp-ip Subject: Re: Seeking answers to Net Problem
In article <[email protected]> [email protected] writes: > >We have a 10base5 Ethernet network with a majority of Vitalink bridges with a >handfull of DEC bridges. We have a DEC VAXStation 3100 Ultrix workstation [some stuff deleted] >The original gateway bridge had an IP address of 156.144.60.2. I assigned the >"new" gateway bridge an address of 156.144.60.40. Then I changed the Ultrix >Wanmanager software to use 156.144.60.40 as the address of its gateway bridge. >The system never came up. I used an HP Lan analyser and saw no traffic between >the Vitalink Gateway bridge (156.144.60.40) and the Ultrix station. I then >tried to ping the new bridge. It failed the ping, than I ARP'd it and that was >successfull. The old bridge could be ARP'd and Ping'd. After alot of time >with Tech support, I finally decided to try a new IP address for the new >bridge. I assigned the bridge the address of 156.144.60.100, then modified the >WanManager software to look for that address. At this point the system came on >line and has been working fine since. > >Now what I don't understand is what really was wrong? I spent a lot of time on >this and did not come away learning anything. The only other thing is that >156.144.60.40 used to be assigned to a cisco router we were testing, but the >router is gone and has been for at least a week. Any answers ...... This is a bit of a long shot because I don't fully understand your configuration, but it may help. The fact that you mention gateways (ie. the Vitalinks) and that you give them IP addresses (which bridges don't need, except for management) makes me think that what you have got on the Vitalinks is *router* functionality or maybe a router you haven't mentioned? If this is the case, you have actually got more than one subnet. However, your IP address is class B (first octet between 128 and 191) and your subnet number for ALL of the devices is 156.144 (implying that they think, if default Class B subnet masking is used, they are all on the same subnet). What subnet masks have you set on all your devices? If its 255.255.0.0 (by default for a Class B) then this could be the problem. If your subnet mask (for some or all devices) is 255.255.255.192 then this *could* explain it, because "100" in the last octet would be interpreted as on a different subnet from "40" and "2" and probably unreachable? Finally, if the subnet mask settings are different between some of the devices this could also explain the problem, and cause others :-) Hope this helps -- Phil Royse Comms Consultant | member: The Peer Association TUDOR HOUSE | (networking & OSI specialists) 12 Woodside Road, Purley Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868
-----------[000027][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 93 08:09:31 GMT From: [email protected] (matthew green) To: comp.protocols.tcp-ip Subject: Re: Writing a new TCP/IP based on raw sockets on Sun4 (OS 4.1.3)
[email protected] (W. Richard Stevens) writes: > Oh, you also need superuser privilege to >create a raw socket. of course, if you are running ESIX, this is false. (unless its been ``fixed'' in a new version) mrg..
-----------[000028][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 Oct 1993 11:38:57 GMT From: [email protected] (Andy McClements) To: comp.protocols.tcp-ip Subject: Opinions wanted on network harware
I'm currently evaluating various vendors routers, hubs, management software etc. which I'll be using to set up a modest multi-protocol internetwork between four of our sites. There'll initially be between 15-25 active users per site, using PC's and Macs, and the traffic between sites will be mainly e-mail and database transactions. The infrastucture will be based on 2Mbit/s fibre links, shared with the voice system by NewBridge multiplexers. The data bandwith between sites will initially be 512kbit/s, (expandable to 1024kbit/s if we opt for compression on the voice channels) and will be presented on X.21 connectors. It seems like there aren't many vendors which do a complete range as mentioned above. The only one I've found so far is HP, who can provide everthing I need to build the internet, from the central router down to individual transceivers. It would certainly make my life a lot easier if I had a single point of contact for support, maintenance etc. and I would think going for a single vendor should minimise interoperability problems. Does anyone have experience of HP hardware, or have any recommendations ? -- -------------------------------------------------------------------------- Andy McClements e-mail: [email protected] Computer Manager applelink: southwark.uk Southwark College voice: 071-815-1522 Drummond Road fax: 071-815-1525 London SE16 4EE --------------------------------------------------------------------------
-----------[000029][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 Oct 1993 12:54:13 GMT From: [email protected] (John Hascall) To: comp.protocols.tcp-ip Subject: Re: HELP! Where do ftp transfers go?
[email protected] (Henry Choy) writes:
}I'm trying to use tcpdump to read the network traffic due to ftp
}activity. When the ftp starts, tcpdump spits out some info, but
}tcpdump stops after that even though I'm transferring millions of
}bytes. Does this mean the information in the file cannot be seen
}with tcpdump?
FTP uses a control connection and a data connection.
It would seem you are watching only the control connection.
See RFC959 (available at your better ftp sites) for details.
John
--
John Hascall ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
-----------[000030][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 Oct 1993 14:19:27 GMT From: [email protected] (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Specifying IP
In article <[email protected]> [email protected] (Tom Fitzgerald) writes: >... >- ... also use a time-synchronization protocol like ntp > (recommended) or timed (not recommended, but sometimes necessary) or > both. Even if you don't use NFS or SMTP, this is worth considering. I know of a major UNIX vendor that ships `timed` turned on, so that there are 10's of 1000's of workstations out there happily using timed, with their clocks synchronized to about 10 ms. Almost all timed problems result from customer improvements to the out-of-the-box configuration or when two different groups of people on the same wire cannot agree on the time. Notice that unnecessary knob TCP/IP twisting is what Mr. Fitzgerald warned against in the rest of his article. A large fraction of all computer problems are "operator assisted." The timed protocol, "TSP", is not what it should have been, and the 4.3BSD implementations was not an admirable piece of code, but in my biased opinion, the 4.4BSD version is sufficiently stable. Timed has one great advantage over NTP, at least as NTP is currently used. Timed can be shipped to work out-of-the-box, so that the customer need not look for a time server and otherwise fiddle with configuration files. Even when you do use NTP (or other protocols) to get the time from a better source, it is best to use NTP on only a few trusted time lords, and let them distribute time via timed-TSP to the local rabble. Maybe NTP implementations will eventually be improved to do that also. Vernon Schryver [email protected]
-----------[000031][next][prev][last][first]---------------------------------------------------- Date: 2 Oct 93 19:12:14 GMT From: [email protected] (Oleg Orel) To: comp.protocols.tcp-ip Subject: Re: libftp libraries on a sun4
Doug Burke ([email protected]) wrote: : Hi. I am trying to get the "libftp" ftp libraries up and running on our : Sun4/360 machine running SunOS 4.1.3 but keep getting core dumps when : trying to run the sample application. It seems to be core dumping when : trying to use the hostname passed to the FtpConnect function. The : "libftp" software was posted to this newsgroup sometime last July. : Has anyone had success with these libraries on their Sun machines? I am : using GCC 2.4.5. Thanks in advance for any information. Email responses : and I'll post if there's interest. : Thanks and cheers, Are you try mailing about this problem to author (me). Your version of libftp don't correct transfer peremeters. Try retrive new version of library from lpuds.oea.ihep.su:/libs and relink it. Peoples!!! If who have ideas about expandet this library , please write mails about it to me... Thanks. Oleg Orel -- --------------------------------------------------------------------------- | Oleg Orel, Russia, Protvino | [email protected] | | Institute of High Energy Physics | Home Phone: 49106 | ---------------------------------------------------------------------------
-----------[000032][next][prev][last][first]---------------------------------------------------- Date: Sat, 2 Oct 1993 23:36:40 GMT From: [email protected] (Andrei Arkhipov) To: comp.protocols.tcp-ip Subject: Re: Class C subnetting
In article [email protected], Alain Struyf <[email protected]> writes: >In article <[email protected]> David Pratt, [email protected] writes: >> We have a new class C Internet number at our school... How do I go about >> subnetting this and why would I want to... > >RFC1219 (On the assignement of subnetnumbers) could be a good start for >you. However, on the why you would want to subnet a class C... > >Alain. Why not? I have a Class C network with subnet mask 255.255.255.224 and have no problems. In the config original author described it's possible to use netmask 255.255.255.192, I think. Andrei.
-----------[000033][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 93 03:57:49 GMT From: [email protected] (Robert Perlberg) To: comp.sys.sun.admin,comp.protocols.tcp-ip Subject: Re: Changing IP addresses (SUMMARY)
Thanks to the responses I received from the net I solved the problem. I brought the system down, changed the /etc/hosts file, deleted the directory containing the NIS maps, and rebuilt the maps with ypinit. I also deleted the files from /var/yp/binding. I don't know whether I needed to do both or which of the two would have been enough, but I didn't have the luxury of enough downtime for experimentation. My theory is that doing the NIS make in single-user mode didn't properly update the maps. I tried doing the NIS make in multi-user mode but that caused the system to hang since it could not access its own NIS. I've never completely understood NIS. It seems so simple, or at least it should be, and yet any time I try to do anything with it I wind up having to rebuild from scratch. I haven't worked with NIS+ (I haven't upgraded to Solaris 2.x yet) so I don't know if it is better in this respect. Robert Perlberg Dean Witter Reynolds Inc., New York [email protected] -or- philabs!dwrsun4!perl
-----------[000034][next][prev][last][first]---------------------------------------------------- Date: 3 Oct 1993 04:47:17 GMT From: [email protected] (Henry Choy) To: comp.protocols.tcp-ip Subject: Re: HELP! Where do ftp transfers go?
John Hascall ([email protected]) wrote:
: [email protected] (Henry Choy) writes:
: }I'm trying to use tcpdump to read the network traffic due to ftp
: }activity. When the ftp starts, tcpdump spits out some info, but
: }tcpdump stops after that even though I'm transferring millions of
: }bytes. Does this mean the information in the file cannot be seen
: }with tcpdump?
: FTP uses a control connection and a data connection.
: It would seem you are watching only the control connection.
: See RFC959 (available at your better ftp sites) for details.
Thanks to all who made suggestions!
I backed off on the filter to see all tcp packets as opposed to
ftp port tcp packets. I saw more of my transfer. I'm
checking to see if I can now see all my transferred data.
--
Henry Choy
[email protected]
Anything worth doing is worth overdoing. - R. Heinlein
is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield
-----------[000035][next][prev][last][first]---------------------------------------------------- Date: Sun, 03 Oct 93 19:53:59 -0600 From: "BSW Gateway" <[email protected]> To: comp.protocols.tcp-ip Subject: Short Course on SNMPv2
| The following message was forwarded from Northeastern University | because of USENET trouble there. Please send all private replies to | "[email protected] (Gisele Crepeau)", not to this gateway system. From: [email protected] (Gisele Crepeau) Organization: Northeastern University Subject: Short Course on SNMPv2 Newsgroups: comp.protocols.tcp-ip October 18-19. SNMPv2: The New Wave in Network Management. William Stallings conducts an intensive short course on SNMPv2, including protocol functions, security features, and coexistence/transition. Cape Cod, MA. Contact: Northeastern University, Center for Continuing Education State-of-the-Art Program, 370 Common street, Dedham, MA 02026. Tel: 617-320-8000 ext. 8052 or 800-367-5376 (outside MA).
-----------[000036][next][prev][last][first]---------------------------------------------------- Date: Sun, 3 Oct 1993 12:42:05 GMT From: [email protected] (Tom Stiller) To: comp.protocols.tcp-ip Subject: Re: audio conferencing software - mbone
In article <[email protected]>, [email protected] (Randy Turner) wrote: > > I am looking for the software that allows internet-wide > audio conferencing between <n> numbered audio-capable > workstations...Recently I heard that it was on one of > the machines in the lbl.gov domain but I forgot which one. > > Also, I believe I will also need the SunOS 4.1 kernel > patches to support IP Multicast. Does anyone know where > these patches are and possibly provide some quick procedure > for building the kernel with these new changes ? > > Thanks! > Randy > Please add my name to the list. Tom Stiller -- Everyone's entitled to my opinion
-----------[000037][next][prev][last][first]---------------------------------------------------- Date: Sun, 3 Oct 1993 14:55:01 GMT From: [email protected] (Ran Atkinson) To: comp.protocols.tcp-ip Subject: Re: Network Time
In article <[email protected]> [email protected] (Vernon Schryver) writes: % Even when you do use NTP (or other protocols) to get the time from a % better source, it is best to use NTP on only a few trusted time lords, % and let them distribute time via timed-TSP to the local rabble. Maybe % NTP implementations will eventually be improved to do that also. I disagree. Timed isn't all that helpful really. The best thing to do is to simply run NTP on all of one's machines. For that matter, if you care about time, you should be running NTP with the DES or MD5 authentication enabled. Ran [email protected]
-----------[000038][next][prev][last][first]---------------------------------------------------- Date: Sun, 3 Oct 1993 19:31:44 +0000 From: [email protected] (Phil Royse) To: comp.protocols.tcp-ip Subject: Re: Opinions wanted on network harware
In article <[email protected]> [email protected] writes: >I'm currently evaluating various vendors routers, hubs, management software >etc. which I'll be using to set up a modest multi-protocol internetwork >between four of our sites. >It seems like there aren't many vendors which do a complete range as >mentioned above. The only one I've found so far is HP, who can provide >everthing I need to build the internet, from the central router down to >individual transceivers. It would certainly make my life a lot easier if I >had a single point of contact for support, maintenance etc. and I would >think going for a single vendor should minimise interoperability problems. > >Does anyone have experience of HP hardware, or have any recommendations ? >Andy McClements e-mail: [email protected].co.uk Andy, This kind of strategic planning is what I do all the time. Regarding HP, I respect them a great deal (and used to work for them in the UK) however, I would not advise a one-stop-shopping approach to all your networking needs. (I wouldn't describe HP as a network design, integration and support company). There are few companies which manufacture and integrate systems and networks satisfactorily. However, the benefits of one-stop-shopping are more than outweighed by your being able to select best of breed from each main technology. I would advise you split your plannig and procurement into: Cabling (UTP, fibre) - specialists cabling installers Repeaters and 10baseT components - speciality LAN companies or hub dealers. (You may want to select the type first, eg. Cabletron, HP Ethertwist, UB, 3Com (British design, ex-BICC ISOLAN) DEChub 90, Synoptics etc. then shop around for the best deal). Bridges & routers next - look to the market leaders (3Com, Wellfleet, Cisco etc. ) unless you are very familiar with installing and configuring routers. Network management systems - as you are unlikely to buy one which supports ALL possible MIB extensions, I would advise that you choose your NMS to manage the hubs as a priority. You can always manage other devices (if their MIB isn't supported) by a telnet session. There are some good "network integration" companies around, such as ACT CableStream, Computer International and Spider Networks (also BT and Hg will bid for big networks) but these companies charge for network design, project management, training courses etc. and I guess you are keen on spending the minimum on these things and doing your own (especially the design!!) Hope this helps (and apologies to any vendors who I've omitted) -- Phil Royse Comms Consultant | member: The Peer Association TUDOR HOUSE | (networking & OSI specialists) 12 Woodside Road, Purley Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868
-----------[000039][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 1993 09:36:52 -0700 From: [email protected] (Douglas C. Schmidt) To: comp.protocols.tcp-ip Subject: Re: Design of parallel TCP. Is it possible ?
++ >> I'm wondering if TCP protocol can be parallelized to make the
++ >> processing of the protocol more effective.
You might want to check out some of the following articles, which are
listed in no particular order. The first three discuss parallelizing
TCP in particular, the next seven discuss parallelizing other
protocols (such as TP4, XTP, IP etc.), and the remaining two discuss
communication framework issues for multi-processor platforms.
My apologies if I've omitted anything or anyone by accident.
Doug
----------------------------------------
@inproceedings{Zitterbart:92d,
AUTHOR ="O.G. Koufopavlou and A. N. Tantawy and Martina Zitterbart",
TITLE = "{Analysis of TCP/IP for High Performance Parallel Implementations}",
BOOKTITLE="17th Conference on Local Computer Networks",
ADDRESS="Minneapolis, Minnesota",
MONTH =sep,
YEAR=1992,
}
@inproceedings{Schwartz:93b,
AUTHOR = "M. H. Nguyen and Mischa Schwartz",
TITLE = "{Reducing the Complexities of TCP for a High-Speed
Networking Environment}",
BOOKTITLE = infocom,
ORGANIZATION="IEEE",
ADDRESS="San Francisco, California",
YEAR = 1993
}
@inproceedings{Bjorkman:93,
AUTHOR = "{Mats Bjorkman and Per Gunningberg}",
TITLE = "{Locking Strageties in Multiprocessor Implementations
of Protocols}",
BOOKTITLE=sigcomm,
ORGANIZATION="ACM",
ADDRESS="San Francisco, California",
YEAR=1993
}
----------------------------------------
@inproceedings{Ito:92,
AUTHOR="M. Goldberg and Gerald Neufeld and Mabo Ito",
TITLE="{A Parallel Approach to OSI Connection-Oriented Protocols}",
BOOKTITLE="Proceedings of the $3^{rd}$ IFIP Workshop on
Protocols for High-Speed Networks",
ADDRESS="Stockholm, Sweden",
YEAR=1992,
MONTH=may,
}
@article{Ito:93,
AUTHOR="Mabo Ito and Len Takeuchi and Gerald Neufeld",
TITLE="{A Multiprocessing Approach for Meeting the Processing
Requirements for OSI}",
JOURNAL=ieeejsac,
MONTH=feb,
YEAR=1993,
PAGES="220--227",
}
@inproceedings{Schwartz:93a,
AUTHOR = "Thomas La Porta and Mischa Schwartz",
TITLE = "{Performance Analysis of MSP: a Feature-Rich
High-Speed Transport Protocol}",
BOOKTITLE = infocom,
ORGANIZATION="IEEE",
ADDRESS="San Francisco, California",
YEAR = 1993
}
@inproceedings{Zitterbart:92c,
AUTHOR ="A. N. Tantawy and Martina Zitterbart",
TITLE = "{Multiprocessing in High Performance IP Routers}",
BOOKTITLE="3rd International IFIP WG 6.1/6.4 Workshop on
Protocols for High-Speed Networks",
ORGANIZATION="IFIP",
ADDRESS="Stockholm",
MONTH =may,
YEAR=1992,
ABSTRACT = ""
}
@inproceedings{Zitterbart:93b,
AUTHOR ="Torsten Braun and Martina Zitterbart",
TITLE = "{Parallel Transport System Design}",
BOOKTITLE="{Proceedings of the 4$^{th}$ IFIP Conference on High
Performance Networking}",
ORGANIZATION="IFIP",
ADDRESS="Belgium",
YEAR=1993,
ABSTRACT = ""
}
@inproceedings{Schwartz:90,
AUTHOR="Jiraj Jain and Mischa Schwartz and Theodore Bashkow",
TITLE="{Transport Protocol Processing at GBPS Rates}",
BOOKTITLE=sigcomm,
ORGANIZATION="ACM",
ADDRESS="Philadelphia, PA",
YEAR=1990,
MONTH=sep,
PAGES="188--199",
}
@article{Haas:91,
AUTHOR = "Zygmunt Haas",
TITLE = "{A Protocol Structure for High-Speed Communication
Over Broadband ISDN}",
JOURNAL = "IEEE Network Magazine",
YEAR = 1991,
MONTH = {January},
PAGES = "64--70",
}
@article{Woodside:89,
AUTHOR = "C. Murray Woodside and J. Ramiro Montealegre",
TITLE = "{The Effect of Buffering Strategies on Protocol
Execution Performance}",
JOURNAL = "IEEE Transactions on Communications",
YEAR = 1989,
}
----------------------------------------
@inproceedings{Presotto:93,
AUTHOR="David Presotto",
TITLE="{Multiprocessor Streams for Plan 9}",
BOOKTITLE="Winter USENIX Conference",
ADDRESS="San Diego, CA",
ORGANIZATION="USENIX",
MONTH=jan,
YEAR=1993
}
@inproceedings{Sequent:90,
AUTHOR="Arun Garg",
TITLE="{Parallel STREAMS: a Multi-Process Implementation}",
BOOKTITLE="Winter USENIX Conference",
ADDRESS="Washington, D.C.",
MONTH=jan,
YEAR=1990
}
--
His life was gentle, and the elements so | Douglas C. Schmidt
Mixed in him that nature might stand up | [email protected]
And say to all the world: "This was a man." | ucivax!schmidt
-- In loving memory of Terry Williams (1971-1991)| (714) 856-4101
-----------[000040][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Oct 1993 01:03:26 GMT From: [email protected] (Don Pace) To: comp.protocols.tcp-ip Subject: NAT IP Routers
I am looking in to setting up a inexpensive network. I have been told that the NAT IB/290 remote IP router is a good choice for wht I am doing, but have not had any experience with them. If you have had any experiences good or bad with them, could you please drop me a note so I know what I am getting into. Thanks Don Pace
-----------[000041][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 1993 03:17:53 GMT From: [email protected] (Henry Choy) To: comp.protocols.tcp-ip Subject: HELP! What protocol do I have?
I have TCP packets transmitted over an ethernet wire.
What protocols are these packets nested in? Is it 802.3?
Is there another level of nesting?
--
Henry Choy
[email protected]
Anything worth doing is worth overdoing. - R. Heinlein
is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield
-----------[000042][next][prev][last][first]---------------------------------------------------- Date: Mon, 04 Oct 93 10:04:04 -0400 From: "Jeff Milloy" <[email protected]> To: comp.protocols.tcp-ip Subject: Vendor MAC Addresses
ISC has developed an Ethernet Bridge w/ISDN, Frame Relay, and Sync access and needs to acquire a block of Vendor MAC Addresses. Can someone please tell me who controls the assignment/purchase of Vendor MAC Addresses these days? Thanks in advance, /Jeff
-----------[000043][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Oct 1993 03:59:46 GMT From: [email protected] (David E Boyes) To: comp.protocols.tcp-ip Subject: Re: Design of parallel TCP. Is it possible ?
In article <[email protected]> [email protected] (Craig Partridge) writes: >> I'm wondering if TCP protocol can be parallelized to make the >> processing of the protocol more effective. > >Leaving aside the notion of what `effective' is, the answer is yes, TCP >can be parallelized, and in ways that make at least some good use of the >multiple processors. Craig mentioned some work. You may also want to check out John Zweig's work at UIUC on parallel IP suites. -- David Boyes | This signature modified to be inoffensive to any race, [email protected] | color, creed, sexual orientation, or programming limitation. My opinion is my | Sober pursuit of truth and to all high ideals consecrated? own. | Look, it says so right on the box, next to the Vitamin A.
-----------[000044][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Oct 1993 04:00:13 GMT From: [email protected] (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Network Time
In article <[email protected]> [email protected] (Ran Atkinson) writes: >In article <[email protected]> [email protected] (Vernon Schryver) writes: > >% Even when you do use NTP (or other protocols) to get the time from a >% better source, it is best to use NTP on only a few trusted time lords, >% and let them distribute time via timed-TSP to the local rabble. Maybe >% NTP implementations will eventually be improved to do that also. > >I disagree. Timed isn't all that helpful really. > >The best thing to do is to simply run NTP on all of one's machines. >For that matter, if you care about time, you should be running NTP >with the DES or MD5 authentication enabled. If you care about time, then I agree that you should be using the current version of NTP with authentication enabled and "peering" with a low stratum server. However, in what way is timed not "all that helpful really"? The vast majority of people who use computers, not to mention the population at large, does not really care, and thinks that a minute or two is "close enough for goverment work." They clearly find discussions of computers that all stay within milliseconds of one atomic clock in a basement somewhere bizarre and/or boring. The vast majority of computer users and operators are like the perverbial VCR owners with the blinking "12:00". Almost all customers do not even set the local timezone. They do not know or care or understand about the implications of network time for things like `make` and NFS. A scheme that automagically causes all computers within broadcast range to the same second, even if it is hours (wrong timezone) plus minutes wrong (based on their setting of Mickey to what the airline attendant said on their last flight) is great. (If time is a hobby, and keep you keep your wristclock within a second or two of WWV, have you ever wondered if the airlines really know how often and how early or late they are? The people who annouce the local time in the airplanes certainly don't know what time it is.) Vernon Schryver [email protected]
-----------[000045][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 93 09:41:56 From: [email protected] (Amos Shapira) To: comp.protocols.tcp-ip Subject: Re: Network Time
[email protected] (Ran Atkinson) writes: (Vernon Schryver) writes: % Even when you do use NTP (or other protocols) to get the time from a % better source, it is best to use NTP on only a few trusted time lords, % and let them distribute time via timed-TSP to the local rabble. Maybe % NTP implementations will eventually be improved to do that also. I disagree. Timed isn't all that helpful really. I didn't see the original question but if you are reffering to the precision timed/timeslave can produce then I must say that I found SGI's bundled timeslave very accurate in following time from a server. The best thing to do is to simply run NTP on all of one's machines. For that matter, if you care about time, you should be running NTP with the DES or MD5 authentication enabled. Does anyone have experience in running xntp3 in a "broadcast-client" mode? It doesn't work for me. Ran [email protected] --Amos -- --Amos Shapira (Jumper Extraordinaire) | "If it was good enough for Jesus C.S. System Group, Hebrew University, | then it is good enough for our kids" Jerusalem 91904, ISRAEL | -- A U.S. Senator [email protected] | about the English language
-----------[000046][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 93 15:43:08 -0600 From: [email protected] To: comp.protocols.tcp-ip Subject: "super" netting class c
If I have 32 consecutive class C addresses that line up on the appropriate bits, can I avoid the need to route between them if I use the following subnet mask? 255.255.224.0 I have tried this with NCSA telnet and it assumes that the 32 class Cs are on the same net. (It does an arp for the other class C address, not the gateway.) I assume that most IP implementations apply masks without considering what address classes are being used. Does anyone know of hidden problems this might create or implementations of IP that consider address class before subnet masking?
-----------[000047][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Oct 1993 09:10:10 GMT From: [email protected] To: comp.protocols.tcp-ip Subject: Re: Windows-based NNTP newsreader
In article <[email protected]> [email protected] (ben elliston) writes: >I'm looking for a Windows-based NNTP newsreader - can someone please point me in the direction of one? (Preferrably shareware/freeware). > >Thanks. > >Cheers, Ben > > * Origin: % EchoSprint: bringing HS/Link to your FrontDoor! % (3:620/262)
-----------[000048][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Oct 1993 09:37:40 GMT From: [email protected] (Samson Chen) To: comp.protocols.tcp-ip Subject: Buffer checking of Socket steam
Dear all tcp-members, Sorry to ask a probably very simple question. When I start a socket connection, how to check if the remote side send any data. So that I can avoid the reading to a socket handle will be suspended until the remode side send something. To check that socket handle as a file handle is useless. Is there any method to perfome such a funtion. I will be very appreciate if someone can tell me some clues about it. Thank you for reading this boring message. *Samson Chen (³¯ ²Ð «T) *[email protected] *department of Computer Science *Chung-Hua Polytechnic Institute, Hsin-Chu, Taiwan
-----------[000049][next][prev][last][first]---------------------------------------------------- Date: Sun, 03 Oct 1993 18:16:00 +1000 From: [email protected] (ben elliston) To: comp.protocols.tcp-ip Subject: Windows-based NNTP newsreader
I'm looking for a Windows-based NNTP newsreader - can someone please point me in the direction of one? (Preferrably shareware/freeware). Thanks. Cheers, Ben * Origin: % EchoSprint: bringing HS/Link to your FrontDoor! % (3:620/262)
-----------[000050][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Oct 1993 11:27:17 GMT From: [email protected] (Adam W. Feigin) To: comp.protocols.tcp-ip Subject: Re: Network Time
[email protected] (Amos Shapira) writes:
>Does anyone have experience in running xntp3 in a "broadcast-client" mode?
>It doesn't work for me.
We've been running it here on a few machines to test it out before
using it more extensively. What version of xntp3 are you using ? I
hadn't tried it until the relatively recent versions.
/AWF
------------------------------------------------------------------------------
Internet: [email protected] Adam W. Feigin
UUCP:{backbones}!iis!feigin Network Systems Manager
Mail: Integrated Systems Laboratory Institute for Integrated Systems
ETH-Zentrum Swiss Federal Institute of Technology
CH-8092 Zurich Zurich, Switzerland
Switzerland
Phone: +41 1 632 50 53 FAX: +41 1 252 09 94
"I'd like to donate my body to science after I die, but I'm afraid its
taken far too much of it already"
-----------[000051][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Oct 1993 15:34:31 GMT From: [email protected] (Vatsan Srivathsan) To: comp.protocols.ibm-main,comp.protocols.tcp-ip Subject: tn3270-ISPF Problem
Hello,
I am trying to use tn3270 from a SUN Sparc server 630 to logon to an IBM mainframe running MVS. I am having a problem bringing up ISPF. It gives me the following error "ISPP330 BDISPMAX EXCEEDED -/-100 DISPLAYS EXCEEDED IN BATCH MODE ON PANEL [email protected]".
I am not sure if tn3270 is able to make a successful 3270 connection. I am able to logon and work on native TSO mode. Did anybody try this before and succeed???. Any help would be appreciated.
Please email to my id [email protected]
Thanks
--
Raj Srivathsan
AT&T Consumer Information Management
[email protected]
[email protected]
-----------[000052][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Oct 1993 15:48:56 GMT From: [email protected] (Constance Harker, 408-295-6239) To: comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.dcom.lans.misc,comp.protocols.nfs Subject: Seminars in Boston, TCP/IP and NFS, Building and Managing TCP/IP WANs
Harker Systems is proud to announce two seminars on TCP/IP Networking in Boston, MA: _TCP/IP, NFS and NIS_ October 25-27, 1993 and _Building and Managing TCP/IP Wide Area Networks_ October 28-29, 1993 These classes are designed for the MIS professional or UNIX System administrator who wishes to install, configure, and debug UNIX Ethernet TCP/IP networks. Configuring and maintaining the Network File System (NFS) and the Network Information Service (NIS) is explained. These classes provide a thorough grounding in the concepts behind installing and managing a TCP/IP network, as well as giving practical suggestions and covering the pitfalls of managing TCP/IP networks. Each course covers a different area of UNIX TCP/IP networking: _TCP/IP, NFS and NIS_ is a solid introduction to TCP/IP networking and using NFS and NIS on a UNIX network _Managing and Building a TCP/IP Wide Area Network_ covers the advanced topics of building and managing a UNIX TCP/IP network Course Fees: _TCP/IP, NFS and NIS_ $1,050 _Building and Managing TCP/IP Wide Area Networks_ $700 Fees include the seminar, seminar notes, lunch, and refreshments. For more information call (408) 295-6239 or send email to [email protected] _TCP/IP, NFS and NIS_ _TCP/IP, NFS and NIS_ covers the IP protocol, the TCP and UDP protocols, IP routing protocols, Berkeley sockets, connecting a UNIX workstation to the network, and the common user network applications, Telnet. FTP, rlogin, rsh, and rcp. The Network File System (NFS) and Network Information Service (NIS) portion of the class covers the Sun Network File System including setting up and managing NFS and NIS, the automounter, NFS debugging, and an overview of NIS+. After this three day seminar you will: *Understand the IP protocols and IP routing *Be able to configure network interfaces, routers, and network daemons *Debug TCP/IP problems using the OSI 7 layer model *Be familiar with the standard Berkeley user networking commands *Use the standard Berkeley TCP/IP networking commands *Set up and manage NFS and NIS *Understand how UNIX system administration is changed with NFS and NIS *Set up and use the automounter *Debug NFS and NIS problems *Tune NFS performance *Understand NIS+ and the migration issues involved Day one: The TCP/IP protocol stack OSI 7 layer model as it relates to the TCP/IP protocol suite The IP network layer protocols TCP/IP packet types The TCP and UDP transport protocols The Berkeley socket interface The Internet routing protocols, RIP (routed) Overview of advanced exterior routing protocols Day two: Common user programs that use the TCP/IP network Telnet, FTP, tftp, rlogin, rsh, and rcp Files that control network access and security An introduction to NFS Remote Procedure Call (RPC) eXternal Data Representation (XDR) Setting up NIS servers Using the NIS databases on client machines Day three: The operational flow of mounting and using an NFS file system Installing and using the automounter Creating and using custom NIS maps Debugging NFS and NIS problems Overview of installing and maintaining NIS+ Prerequisites: Attendees should have a working knowledge of UNIX commands and a basic understanding of UNIX system administration For more information call (408) 295-6239 or send email to [email protected] _Managing and Building a TCP/IP Wide Area Network_ _Managing and Building a TCP/IP Wide Area Network_ covers the issues and responsibilities of building and managing a UNIX TCP/IP network. This course was designed for the MIS professional or UNIX system administrator who want to understand the technologies used in building a Wide Area Network (WAN) using TCP/IP routers, dial-up phone lines, and leased lines. The course covers: The Simple Network Management Protocol (SNMP) and the domain naming system (named) as tools to aid in management. Connecting groups of Local Area Networks (LAN) into campus Metropolitan Area Networks (MAN) or global Wide Area Networks (WAN). Technologies for building a Wide Area Network (WAN) using TCP/IP routers, dial-up phone lines, and leased lines. Building a back-bone corporate Metropolitan Area Network (MAN) by connecting Ethernet LANs using a fiber optic FDDI backbone. After this two-day seminar you will: *Understand the mechanics of managing a TCP/IP network, and what tools and procedures are recommended *Create consensus in the user community between users and network managers *Be able to configure, use and maintain the domain naming system (named) *Be familiar with the Simple Network Management protocol (SMNP), SNMP Network Management Stations and SNMP Agents. *Understand how to combine the different LAN, MAN, and WANs in to robust internet network *Configure the LANs and backbone of a campus location into a self contained MAN *Use the MANs as building blocks to create the corporate WAN *Use the IP routing protocols to create universal connectivity while maintaining control over what connectivty is allowed *Connect a corporate WAN to the world wide Internet *Be able to protect network security by building a firewall router *Understand the issues of reliability, performance, and network security Day one: The domain naming system (named) Network management tasks Organizing your user community Simple Network Management Protocol (SNMP) Monitoring the network Day two: Understanding TCP/IP routers TCP/IP routing protocols used with WANs Exterior Gateway Protocol (EGP) Boarder Gateway Protocol (BGP) Open Shortest Path First (OPSF) Leased line circuits types and services Digital fractional T1, T1, and T3 An introduction to advanced telecom standards ISDN, Frame Relay, SMDS, ATM Building a campus network using FDDI Building a WAN using leased lines Building a WAN using dial-up phone lined lines and Point to Point Protocol (PPP) Connecting to the Internet Building a firewall router WAN network security Working with your long distance service provider Prerequisites: _TCP/IP, NFS and NIS_ course or equivalent experience. Attendees should have a working knowledge of UNIX system administration and setting up TCP/IP networks. For more information call (408) 295-6239 or send email to [email protected]
-----------[000053][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 1993 18:37:21 GMT From: [email protected] (Clark Gaylord) To: comp.protocols.tcp-ip Subject: Re: Ftp script
Damoder Donur ([email protected]) wrote: : i would like to know is there any ftp script that I can put into : cron file to get the file from the pc which is connected to network. The only way I have been able to do this is by having ftp read from stdin. Try: --- begin junk --- anonymous [email protected] cd /pub/mystuff get thisstupidfile.txt quit --- end junk --- $ ftp < junk Clark
-----------[000054][next][prev][last][first]---------------------------------------------------- Date: Mon, 04 Oct 93 19:07:10 +010 From: [email protected] (Bernard.Guillaumot) To: comp.protocols.tcp-ip Subject: TN5250
Hi,
Can someone please advise me on the TCP/IP products (free or commercials)
with support of TN5250 (Telnet 5250) and/or TN3270 (Telnet 3270), for :
1) PCs - DOS with/without Windows ?
2) Unix platforms (Risc, Cisc) ?
3) others systems like VMS ?
Mabe you can help me by the addresses (postal, fax, email, ..) of
providers/vendors of these products and any details regarding them.
Any help you can give will be gratefully appreciated.
Best regards.
Bernard.
--
[email protected] (Bernard.Guillaumot)
T.nis - Telecoms dedicated private server : (33)-{1}46-085-205 - GMT+0100
-----------[000055][next][prev][last][first]---------------------------------------------------- Date: 4 Oct 93 20:39:49 GMT From: [email protected] (Russell Nelson) To: comp.protocols.tcp-ip Subject: Writing a new TCP/IP based on raw sockets on Sun4 (OS
In article <[email protected]> [email protected] writes: [email protected] (W. Richard Stevens) writes: > Oh, you also need superuser privilege to >create a raw socket. of course, if you are running ESIX, this is false. (unless its been ``fixed'' in a new version) Could be. ESIX is under new management, and they take bug reports very seriously. -russ <[email protected]> What canst *thou* say? Crynwr Software Crynwr Software sells packet driver support. 11 Grant St. 315-268-1925 Voice | LPF member - ask me about Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
-----------[000056][next][prev][last][first]---------------------------------------------------- Date: 04 Oct 1993 22:05:46 GMT From: [email protected] (Duane T. Mun) To: comp.protocols.tcp-ip Subject: Re: Ftp script
"Damoder" == Damoder Donur <[email protected]> writes: Damoder> i would like to know is there any ftp script that I can put Damoder> into cron file to get the file from the pc which is connected Damoder> to network. Try this... ------------------------------------- ftp -n << EOFTP open <machine name> user <login name> <password> <commands> ... quit EOFTP ------------------------------------- -- dtm
-----------[000057][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 1993 05:00:49 -0400 From: [email protected] (Erik Heimdahl) To: comp.protocols.tcp-ip Subject: Sockets and bind...
I have just started testing to write some small testprograms for communication between Unix-mashines. I have the book "Internetworking with TCP/IP vol 1" by Douglas.E.Comer and on page 360 is an example program that i wanted to test. When started, an errorcode from bind is returned. bind: Can't assign requested address. The errno variable is 49 Why isn't the test-program executed properly ?? My hardware is a NeXT Station Color. I'm member of the group "operator" Whats wrong ??? /erik PS. _PLEASE_ anwser by mail ([email protected]), since I don't recieve this newsgroup. DS.
-----------[000058][next][prev][last][first]---------------------------------------------------- Date: Mon, 4 Oct 1993 23:18:53 GMT From: [email protected] (Sam Yee) To: comp.protocols.tcp-ip Subject: telnet and term emulation recognition
When I telnet from one machine to another, how does the destination machine know what terminal emulation I am using? Off course, this doesn't always happen, so I want to know how to make it always happen. thanks, -sam P.S. Please reply by e-mail as I don't read this newsgroup often.
-----------[000059][next][prev][last][first]---------------------------------------------------- Date: Mon, 04 Oct 1993 08:29:03 +1000 From: [email protected] (ben elliston) To: comp.protocols.tcp-ip Subject: Windows-based NNTP newsreader
> I'm looking for a Windows-based NNTP newsreader - can > someone please point me in the direction of one? > (Preferrably shareware/freeware). I found one! Trumpet for Windows is available on ftp.utas.edu.au for anyone who was also interested in such a beast. Cheers, Ben * Origin: % EchoSprint: bringing HS/Link to your FrontDoor! % (3:620/262)
-----------[000060][next][prev][last][first]---------------------------------------------------- Date: 05 Oct 1993 02:20:28 GMT From: [email protected] (Paul Traina) To: comp.protocols.tcp-ip, [email protected] Subject: Re: "super" netting class c
In article <[email protected]> [email protected] writes: Path: cronkite.cisco.com!decwrl!spool.mu.edu!umn.edu!msus1.msus.edu!msus1.msus.edu!news Newsgroups: comp.protocols.tcp-ip From: [email protected] Date: 04 Oct 1993 13:43:08 PST Reply-To: [email protected] Organization: Winona State University - minnesota Nntp-Posting-Host: 134.29.91.32 X-Newsreader: IBM NewsReader/2 v1.00Lines: 9 Lines: 9 If I have 32 consecutive class C addresses that line up on the appropriate bits, can I avoid the need to route between them if I use the following subnet mask? 255.255.224.0 I have tried this with NCSA telnet and it assumes that the 32 class Cs are on the same net. (It does an arp for the other class C address, not the gateway.) I assume that most IP implementations apply masks without considering what address classes are being used. Does anyone know of hidden problems this might create or implementations of IP that consider address class before subnet masking? It sounds to me as if you're trying to BRIDGE together thirty-two class C networks, since you want to be able to ARP to a different network number but still expect to get there (unless you are holding the world together by proxy-arp). That's not really what we intended when CIDR was being written, and you may have some "backwards compatibility" problems with routers that aren't aware of supernets (and routing protocols that don't cary netmask information).
-----------[000061][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 03:01:33 GMT From: [email protected] (Tom Fitzgerald) To: comp.protocols.tcp-ip Subject: Re: Specifying IP
[email protected] (Vernon Schryver) writes: > I know of a major UNIX vendor that ships `timed` turned on, so that there > are 10's of 1000's of workstations out there happily using timed, with > their clocks synchronized to about 10 ms. I think I know which one you mean.... but didn't this vendor also make some changes to timed, to avoid chasing after bad clocks, jumping the time unnecessarily, etc? These are constant problems with the usual timed - I guess we should distinguish between the timed protocol (which is fine for non-obsessive applications) and timed implementations, which tend to have some really pathological behavior. Maybe this was fixed in BSD 4.4, but nearly all vendor code is BSD 4.3-derived, at best, and porting socket- intensive code to some real-world systems is a real pain. > Timed has one great > advantage over NTP, at least as NTP is currently used. Timed can be > shipped to work out-of-the-box, so that the customer need not look for a > time server and otherwise fiddle with configuration files. > Even when you > do use NTP (or other protocols) to get the time from a better source, it > is best to use NTP on only a few trusted time lords, and let them > distribute time via timed-TSP to the local rabble. Maybe NTP > implementations will eventually be improved to do that also. NTP can do this. The easiest way to set up ntp is to fully configure the timelords, as you say, then set up everyone else with only a single config file line: "broadcastclient yes". Even with timed, you have to set -M on at least one of the systems.... With NTP broadcastclients everywhere, the only disadvantage of NTP is increased real memory usage. (And I do have timed running here on systems that are extremely tight on RAM.) The advantages are greater accuracy, resistance to bad clocks, better trace information in case of problems, and smoother slewing of the clocks. -- Tom Fitzgerald Wang Labs, Lowell MA, USA [email protected] 1-508-967-5278
-----------[000062][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 93 12:09:09 CDT From: [email protected] (Timothy Bilbrey) To: comp.protocols.tcp-ip Subject: Re: Can I have IPX and TCP/IP at the same ti
Where can I obtain ipxtcp.com
I presently am running ipx and ip Ie: ncsa telnet on my Novell Workstations
my netware boot file looks like this
cd\net
ipx
netx
w8003pkdr (SMC Elite16 packetdriver)
Would ipxtcp work better. Where can iget this generic packetdriver
-----------[000063][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 93 09:28:34 GMT From: [email protected] (Domini) To: comp.protocols.tcp-ip Subject: OSPF SLIP/PPP ...
Does anyone out there have, or know of a place where I can find FAQs for OSPF or SLIP/PPP ? I am confused as to what these actually are, and what the issues are surrounding them. Any info can also be mailed to : [email protected] thnx. Marius van Wyk.
-----------[000064][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 1993 08:45:00 +0100 From: [email protected] (Jan-Piet Mens) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: PC-NFS 5.0 over packet driver ?
I would like to run PC-NFS 5.0 over a packet driver. I believe I need a new \NFS\PCNFS.SYS for this. Can someone enlighten me ? Where can I get the PCNFS.SYS file for packet driver (archie doesn't say much... :-) Regards, Jan-Piet -- Jan-Piet Mens [email protected] ASK Ingres GmbH, Frankfurt, Germany +49 69 66413-285
-----------[000065][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 1993 11:42:48 GMT From: [email protected] To: comp.protocols.tcp-ip Subject: Re: Ftp script
In article <[email protected]>, [email protected] (Duane T. Mun) writes: >"Damoder" == Damoder Donur <[email protected]> writes: > >Damoder> i would like to know is there any ftp script that I can put >Damoder> into cron file to get the file from the pc which is connected >Damoder> to network. > >Try this... > >------------------------------------- >ftp -n << EOFTP > open <machine name> > user <login name> <password> > <commands> > ... > quit >EOFTP >------------------------------------- > >-- dtm If you want to eliminate the "open" and "user" lines put the following entry into $HOME/.netrc: machine <MACHINE YOU WANT TO CONNECT TO> login <LOGINNAME> password <PASSWORD> If my machine is prosserv, this is my script: ftp prosserv << EOF <commands> ... quit EOF Hope this helps, jg
-----------[000066][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 1993 12:26:59 GMT From: [email protected] (Gareth W Davies - Systems Engineer Stavanger) To: comp.protocols.tcp-ip Subject: Re: HELP! What protocol do I have?
TCP is an IP based protocol. so TCP goes in IP goes in Ethernet packet. Helps? GWD
-----------[000067][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 13:22:46 GMT From: [email protected] To: comp.protocols.tcp-ip Subject: good book for tcp/ip
Can someone direct me to a good book for tcp/ip?? The book should also include program to explain the implementation. If you have the book, would you please also tell me the publisher so that I can order it from the bookstore. Thanks!!!
-----------[000068][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 13:45:55 GMT From: [email protected] (Roger Hunen) To: comp.protocols.tcp-ip Subject: Re: Buffer checking of Socket steam
In article <[email protected]> [email protected] (Samson Chen) writes: > Sorry to ask a probably very simple question. When I start a socket >connection, how to check if the remote side send any data. So that I can >avoid the reading to a socket handle will be suspended until the remode side >send something. To check that socket handle as a file handle is useless. >Is there any method to perfome such a funtion. > I will be very appreciate if someone can tell me some clues about >it. There are basically 2 ways of doing this: 1. If you have multiple sockets and just need to wait for data on any of these, read & process it and then go to sleep again, you can use select(). 2. If you have other useful things to do and want to process incoming data on a socket in an asynchronous fashion, you can setup a signal handler for SIGIO. The socket must be configured to generate the SIGIO signal using fcntl() calls. These methods are described in the SunOS Network Programming Guide. I assume identical or similar mechanism exist on other systems. Regards, -Roger
-----------[000069][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 1993 14:32:24 GMT From: [email protected] (Gerard Hickey) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Is RMON a standard yet?
Can anyone out there tell me if RMON has become a standard yet? If it is not a full standard, what are the groups that have been stand- arized? Thanks.. Gerard. ------------------------------------------------------------------- Gerard Hickey [email protected] Cabletron Systems, Inc. +1 603 337 1577 My employer probably thinks that I don't have any ideas of my own!! -- Gerard. ------------------------------------------------------------------- Gerard Hickey [email protected] Cabletron Systems, Inc. +1 603 337 1577
-----------[000070][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 14:32:26 GMT From: [email protected] (Scott VanArtsdalen) To: comp.protocols.tcp-ip Subject: Re: Opinions wanted on network harware
[email protected] (Andy McClements) writes:
( Text Deleted )
>It seems like there aren't many vendors which do a complete range as
>mentioned above. The only one I've found so far is HP, who can provide
>everthing I need to build the internet, from the central router down to
>individual transceivers. It would certainly make my life a lot easier if I
>had a single point of contact for support, maintenance etc. and I would
>think going for a single vendor should minimise interoperability problems.
>Does anyone have experience of HP hardware, or have any recommendations ?
>Andy McClements e-mail: [email protected]
Heh, heh, heh. Be afraid...be very afraid. Try reading comp.sys.hp
sometime for a complete description of "HP Support." Their customer reps
screw orders up all the time, the maintenace contracts are consistantly
incorrect, and most of their support people haven't been able to help us.
Now, not all HP customers have had as bad a time as we but many have. Their
hardware seems to be top notch but their support has a ways to go to catch
up.
If you are going to incorporate HP products into your net then comprising
your net totally of HP products would be a good (albeit expensive) way to
go. If you mix vendor products in your net you're likely to get some finger-
pointing from HP when something goes wrong.
Good luck at any rate...
--------------------------------------------------------------------------
\ /\ Aeronca 7AC Champ
\ /__\ =(*)= N3115E =(*)=
Scott \/an \rtsdalen "The Boonie Bouncer"
--------------------------------------------------------------------------
Opinions expressed here do not necessarily reflect those of
Lockheed Missiles & Space Co., Inc. or its management. =*
--------------------------------------------------------------------------
-----------[000071][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 15:00:16 GMT From: [email protected] (Kavetta Ameen) To: comp.protocols.tcp-ip Subject: Re: HELP! What protocol do I have?
I've used those cards with novell before and I'am 99% sure the 3c501 driver is the one you want. The switchs on the card should not be changed except as a last resort. The only switch I ever changed was the interupt number from 3 to 5. ********************************************************************** From: Bob Bellavance [email protected] **********************************************************************
-----------[000072][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 15:41:52 GMT From: [email protected] (Leigh Dodd) To: comp.protocols.tcp-ip Subject: PC-NFS 5.0 on a IBM XT *#%$&^^&
Hi All
I'm just put PC-NFS V5.0 on a IBM XT and run into a few problems so I
hope someone can help ?.
Problem 1.
I want to use PCNFSLPD to make the XT into a print server, when
I run "pcnfslpd -P LPT1: xtp -d" I get the following error :-
"NFSP004 Enviroment variable NFSDRIVE is unusable"
NFSDRIVE IS SET in the autoexec "SET NFSDRIVE=C"
Problem 2.
If I use nfsconf and set up a connection to a remote printer, I
only get the option of LPT2 or LPT3. What happened to LPT1 ?. NOTE. This is with
pcnfslpd NOT running.
Any help please
Leigh
--
*******************************************************************************
* Leigh Dodd (Sun System Administrator) | Three Steps to Heaven *
* University of Sussex | 1). C.B.T. ----- Passed *
* Brighton, England. | 2). Part 2 ----- Passed *
* INTERNET: [email protected] | 3). Gota GPz550 and Riding To HELL *
*******************************************************************************
-----------[000073][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 16:00:21 GMT From: [email protected] To: comp.protocols.tcp-ip Subject: good book for tcp/ip II
If you read my previous mail and would like to e-mail to me, the e-mail address of the previous post is not quite correct. My E-mail address is [email protected] Thanks!!
-----------[000074][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 17:04:19 GMT From: [email protected] (Karl Braun) To: comp.protocols.tcp-ip Subject: Re: Class C subnetting
In article <[email protected]> [email protected] writes:
>>
>>RFC1219 (On the assignement of subnetnumbers) could be a good start for
>>you. However, on the why you would want to subnet a class C...
>>
>>Alain.
>
>
>Why not?
He probably wanted to know why you would want to go through the
trouble and expense of routing when you only have (at max) 254 nodes
on the network.
Of course, the answer could be any of:
1) Security between nodes.
2) Reliability of segments ("dirty" test network vs. production
and development network).
3) Needs for testing across routers.
etc.
kral 408/647-6112
Network Scapegoat in Training NOVELL/DSG
That's the whole problem with science. You've got a bunch of empiricists
trying to describe things of unimaginable wonder." - Calvin
-----------[000075][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 17:27:29 GMT From: [email protected] (matthew lucas) To: comp.protocols.tcp-ip Subject: Source Routing
I want to able to source route across the Internet, but I can't find the right option to use with setsockopt. Does anybody know how to do this? Thanks for any references or suggestions. Matt.
-----------[000076][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 17:51:58 GMT From: [email protected] (Dennis Coyle) To: comp.protocols.tcp-ip Subject: Subnet Addressing Summary
Orginal Question:
-----------------
I looked at D. Comer's book and RFC950, but I am still not sure if you can
have a subnet address of all zeros. Given the following IP address and Subnet
mask:
Class B Address: 149.64.0.0
Subnet Mask: FF.FF.F8.00 (i.e. 255.255.248.0)
I am reserving 5 bits for subnet addressing and 10 bits for hostids. In most of
the examples, it is stated that the first available subnet would have an
IP address of 149.64.8.X. My question is what happens if you have an
IP address of say 149.64.1.1 ? Is it mapped into subnet 0 hostid 257?
(i.e., see example below)
255.255.248.0 => FF.FF.F8.00 (Subnet mask)
149.64.1.1 => 95.40.01.01 (IP address)
95.40.00.00 => 149.64.0.0 & hostid of 257 ??
My confusion stems from the fact that some of the examples state that a
5-bit subnet address field will yield 32 physical subnets, but RFC940 states
that "...subnets of all zeros and all ones in the subnet field should not be
assigned to actual (physical) subnets". I understand why you wouldn't
what all 1's, but I do not understand the all 0's.
P.S. Excuse my ignorance, but this is all new stuff for me. Also, I'm not
a regular reader of the group so I would appreciate direct mail. Howerver,
I wll post a summary of the answers.
Thanks in advance
*****************************************************************************
Summary of Responses:
--------------------
...All zeroes in a field means "this network|subnet|host", just as all ones
means "all networks|subnets|hosts." It is never sent, but could be used
in configuration for example. Since it isn't sent, the code can be hacked
to allow it to be used as an address or subnet number and some stacks do
this. RFC 1122, says the same thing RFC 942 does. I wouldn't use it myself
since in a large network you are guaranteed to run into a stack sooner or
later that doesn't support it...
...From what I've been told and seen (on our bridges) 0.0.0.0 is an old unix
broadcast which still exists for upwardly compatability. And I think that
the others i.e 139.78.255.255 and 139.78.0.0 are also limited broadcasts and
mean the same thing.
...The all 1's is broadcast, and the all zero's combination usualy means: "This
net" or in your case "this subnet". This can be used by a sending host if for
some reason, he doesn't know in what subnet he himself is located.....
..I agree that very often the situation with "all zero's, host zero's or subnet
zero's" is very unclear, especialy since a lot of people "misuse" the "whatever
zero's" combination as an alternative to broadcasting.
As a general guideline, it is good practise to avoid a subnet "all zero" as
well as a subnet "all one" in order to avoid problems....
....If you reference RFC 950, it states the following (referencing RFC 943):
... When such usage is called for, the address zero
is to be interpreted as meaning "this", as in "this
network".... the address 0.0.0.37 could be interpreted
as meaning host 37 on "this" network.
It also has other examples.
RFC 1009 states: "No subnet should be assigned the value zero or -1 (all
one bits).
In practice, I don't think I've seen anyone using zeros to indicate
this address (bootp or RARP, maybe?), but everyone adheres to this
convention and avoids assigning the all zeros subnet.....
RFC References: RFC1219, RFC1009, RFC950, RFC1122, RFC942
Thanks to all that applied, I hope this helps out some other newbe :) !
-----------[000077][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 1993 18:00:36 GMT From: [email protected] (Henry Choy) To: comp.protocols.tcp-ip Subject: Re: HELP! What protocol do I have?
Henry Choy ([email protected]) wrote:
: I have TCP packets transmitted over an ethernet wire.
: What protocols are these packets nested in? Is it 802.3?
: Is there another level of nesting?
I've had a number of very helpful responses! TANX!
--
Henry Choy
[email protected]
Anything worth doing is worth overdoing. - R. Heinlein
is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield
-----------[000078][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 18:16:25 GMT From: [email protected] (Tim Wynn) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Is NIC running out of unique IP addresses?
This may be a foolish question, but I'm too much of a novice
about TCP/IP to know.
I work for a small software company that is a reseller of
UNIX systems, which also sells medical treatment software. When we
ship systems out into the field, we will supply them with a unique
domain name and range of IP addresses that we (supposedly) will get
from NIC. We have not done this yet, but it is a requirement for
when our software ships.
One of my co-workers is in a UNIX course on TCP/IP right
now, and he tells me that his instructor said that NIC is running
out of unique IP addresses. Because of this, he says, NIC is
calling people to ask for any unused addresses they might have
requested in the past. Furthermore he said, it's next to impossible
to get contiguous blocks of addresses anymore, and getting any
addresses takes 6 weeks or more.
Is there any truth to any of this? It sounds absurd to me,
but I don't know enough to confirm or refute it. It would seem that
this situation would be so serious that I would have heard about it
by now. Does anybody know the truth? I'm having this co-worker
place a call to NIC to find out.
Thanks for any light some knowledgeable person might shed on this.
Tim Wynn ([email protected])
=======================================================================
"The difference between writing fiction and non-fiction is that
fiction has to make sense."
- Tom Clancy
=======================================================================
_/_/_/_/ _/ _/ _/_/_/_/ COMPUTERIZED MEDICAL SYSTEMS, INC.
_/ _/_/ _/_/ _/ 56 Worthington Dr.
_/ _/ _/ _/ _/_/_/_/ Maryland Heights, MO USA 63043
_/ _/ _/ _/ tel: 314 434 4394
_/_/_/_/ _/ _/ _/_/_/_/ fax: 314 434 3936
-----------[000079][next][prev][last][first]---------------------------------------------------- Date: 5 Oct 1993 15:13:54 +0200 From: [email protected] (Ralf U. Holighaus) To: comp.protocols.tcp-ip Subject: Re: TN5250
[email protected] (Bernard.Guillaumot) writes: We have implemented a commercial tn3270 application called IP/3270 supporting 3278 and 3279 terminals with several submodels, colors and extended highlighting. It runs well on SCO UNIX and SCO XENIX, ports to other platforms will follow on demand. >Can someone please advise me on the TCP/IP products (free or commercials) >with support of TN5250 (Telnet 5250) and/or TN3270 (Telnet 3270), for : >1) PCs - DOS with/without Windows ? planned. >2) Unix platforms (Risc, Cisc) ? SCO UNIX, SCO XENIX, SCO Open Desktop (in work as GUI version) >3) others systems like VMS ? nope. Regards Ralf. -- Ralf Holighaus | XLINK-POP Stuttgart | Voice: PEM GmbH | Mail * News * ftp * Internet | +49.711/713045 Vaihinger Str. 49 | 2 Modems V32bis/V42bis | Fax: D-70567 Stuttgart, Germany | ISDN-Zugang (netISDN/netGW) | +49.711/713047
-----------[000080][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 19:19:05 GMT From: [email protected] (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Specifying IP
It could be argued that all of this belongs in some other newsgroup. In article <[email protected]> [email protected] (Tom Fitzgerald) writes: >[email protected] (Vernon Schryver) writes: > >> I know of a major UNIX vendor that ships `timed` turned on, so that there >> are 10's of 1000's of workstations out there happily using timed, with >> their clocks synchronized to about 10 ms. > >I think I know which one you mean.... but didn't this vendor also make some >changes to timed, to avoid chasing after bad clocks, jumping the time >unnecessarily, etc? These are constant problems with the usual timed - I >guess we should distinguish between the timed protocol (which is fine for >non-obsessive applications) and timed implementations, which tend to have >some really pathological behavior. Maybe this was fixed in BSD 4.4, but >nearly all vendor code is BSD 4.3-derived, at best, and porting socket- >intensive code to some real-world systems is a real pain. Yes, I made many changes to the 4.3BSD timed code over the years, and sent the results to be included in 4.4BSD. Since then I've found and fixed a few more minor problems, although considering the history of the code, I could have introduced those bugs. SVR4.1 and later STREAMS have much better socket emulation libraries. I can't think off hand of anything in any of the timed code that seems likely to be problematic even for older STREAMS, with the possible exception of sending and receiving ICMP timestamps. The 4.4BSD timed works fine on BSD386 and 386BSD 0.1. ... [about working out-of-the-box] >Even with timed, you have to set -M on at least one of the systems.... NO! NO! NO! EACH AND EVERY TIMED SHOULD BE RUNNING WITH -M EVERYWHERE! Sorry, but I've heard and fought that nonsense so many times that it is very painful. Absolutely no changes need or generally should be made to systems from that vendor to have them properly synchronized "out of the box" by timed. They are shipped with timed running -M (and with "timetrim" turned on). "-M" does not make a timed daemon a master in a sense that any reasonable person would understand "master." Instead, they should have used the word "moderator." -M only lets a daemon volunteer (get "elected") to collect and average participating machines' times and redistribute the result. Any machine that is stable and secure enough to have its time averaged is good enough to act as moderator. About only the reason to turn off -M is to mess up time in a network, although the perpetrators usually do not realize or acknowledge as much. >With NTP broadcastclients everywhere, the only disadvantage of NTP is >increased real memory usage. (And I do have timed running here on systems >that are extremely tight on RAM.) The advantages are greater accuracy, >resistance to bad clocks, better trace information in case of problems, and >smoother slewing of the clocks. You didn't mention that modern versions of NTP can include authentication, or that NTP time has always carried an indication of the accuracy of the source. I have no doubt that NTP is far more accurate than timed. The 4.4BSD timed can slew the clocks as smoothly as possible. If you turn on (and port to your system) the ifdef'ed out code, timed does better than NTP, since it uses the kernel "timetrim" stuff to adjust the raw clock frequency (unless you also use "timetrim" with NTP, or the NTP new system call ideas that I understand to have similar aims). Even without "timetrim", 4.4BSD timed has some hacks to slew the clock more smoothly as time get closer. NTP does have better resistance to intermittently bad clocks, although 4.4BSD timed can be told to ignore lists of bad clocks. I have heard claims that NTP uses far more CPU cycles than a point-to-point hack named "timeslave", which uses ICMP timestamps, the UDP time port, and lots of naive filtering to ride even intermittently asymmetrically loaded low speed links. Vernon Schryver [email protected]
-----------[000081][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 20:40:33 GMT From: [email protected] (O.P.P) To: comp.protocols.tcp-ip Subject: Re: Ftp script
In article <[email protected]>, [email protected] (Damoder Donur) writes:
|> Hello tcp-ip experts:
|>
|> i would like to know is there any ftp script that I can put into
|> cron file to get the file from the pc which is connected to network.
|>
|> I am administering Rs/6000 servers running AIX(3.2) and also running tcp-ip
|> using ethernet interface.
|>
|> Everyday I am manually ftping to pc getting some files. So instead of
|> doing manually is there any script which will automaticall connect to that pc
|> and get the file from pc to rs/6000.
|>
|> Thanks
|>
|> Damoder Donur
|> System Administrator
|>
|>
|> email Address:
|>
|> [email protected]
|> -------------------------------------------------------------
One way would be to add the following to a script
------------------start here-----------------
(
echo user username passwd
echo cd d:\data
echo get data.dat /usr/tmp/pc/data
echo quit
) ftp -n ibmpc > /dev/null
-----------------end------------------------
o.p.p
-----------[000082][next][prev][last][first]---------------------------------------------------- Date: Tue, 5 Oct 1993 21:57:43 GMT From: [email protected] (W. Richard Stevens) To: comp.protocols.tcp-ip Subject: Re: Source Routing
> I want to able to source route across the Internet, but I can't find > the right option to use with setsockopt. Does anybody know how to do > this? Thanks for any references or suggestions. Fetch the file networking/ip/trace/traceroute_pkg.tar.Z from ftp.uu.net and look at the file LSRR.patches. It contains actual code that shows how to set the souce rout option. You want the IP_OPTIONS socket option, but need to be careful getting all the fields correct. Rich Stevens ([email protected])
-----------[000083][next][prev][last][first]---------------------------------------------------- Date: Wed, 06 Oct 93 08:13:22 -0400 From: "Kenneth Chin" <[email protected]> To: comp.protocols.tcp-ip Subject: ARP entry timeouts
I'm just curious about what the standard ARP cache entry timeout may be for routers when they're performing proxy-arp'ing? In most cases, I believe that this is configurable, but what do people usually set it at? Thanks, Ken Chin Pariclete Systems, Inc. (212)249-0931 [email protected]
-----------[000084][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Oct 1993 02:36:24 GMT From: [email protected] (Scott Neugroschl) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Wollongong and SCO ODT 2.0
Hi. I'm running SCO ODT 2.0 as an LPD server. On another 486 PC, I'm running Wollongong Pathway Access and Pathway Client NFS. The Network Driver for Windows installed. We have an HP LJ4 hooked up to the ODT system. When we print from Windows to the LJ4 over the net, we get garbage on the printout. I believe it is because there is no way to pass the -oraw option to the SCO spooler. I would like to know if anyone else is using this sort of configuration, and if so, if they have gotten this to work. Thanks -- Scott "The Pseudo-Hacker" Neugroschl -- Beat me, Whip me, make me code in Ada
-----------[000085][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 1993 14:13:20 -0500 From: [email protected] (Devin Cassas) To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: IP over VSAT network
I have RS/6000s communicating over a Hughes VSAT network. The RS/6000s are running TCP/IP and the application is having problems with timeouts. Packets are always delivered reliably, but I'm not sure about the round trip time. PING gives me consistantly round trip times in the 3-7 second (yes thats SECONDS) range. My question is: does anybody have any experience or knowledge of tuning the TCP/IP protocol stack to make it work better over satellite network? If it helps, the IP is encapsulated in SNA at the earth station before it is beamed into space. Thank you for your help. Devin Cassas [email protected]
-----------[000086][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 1993 07:20:14 GMT From: [email protected] (Tony Li) To: comp.dcom.sys.cisco,comp.protocols.tcp-ip Subject: Re: Host routes on Cisco?
In article <[email protected]> [email protected] (Tom Fitzgerald) writes:
Do Ciscos support host-routes at all? I've been doing some experiments
trying to short-cut paths for multihomed hosts, and it appears that Ciscos
ignore the host part of any route, whether it's received via RIP or given
as a static route.
Has anyone managed to get this working? Or, is this a to-be-supported
feature? Thanks for any info.
Yes, but you need version 9.1.
Tony
-----------[000087][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Oct 1993 08:03:50 GMT From: [email protected] (Norbert G. Hanke) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: PC-NFS 5.0 over packet driver ?
In article <[email protected]> [email protected] (Jan-Piet Mens) writes: >I would like to run PC-NFS 5.0 over a packet driver. I believe I >need a new \NFS\PCNFS.SYS for this. Can someone enlighten me ? >Where can I get the PCNFS.SYS file for packet driver (archie doesn't >say much... :-) You just need PKTD40A.SYS as a driver shim to interface to the packet driver. It is available from bcm.tmc.edu. Norbert Hanke Power Electronics Lab, ETH Zurich, Switzerland
-----------[000088][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 93 16:06:47 From: [email protected] (Rens Troost) To: comp.protocols.tcp-ip Subject: Re: Network Time
In article <[email protected]> [email protected] (Amos Shapira) writes:
Does anyone have experience in running xntp3 in a "broadcast-client" mode?
It doesn't work for me.
What breaks? We're running it in that mode here, and it works fine. I
must ssay it makes life a whole lot easier in a dynamic environment.
-Rens
--
o===============================================================o
| J. Laurens Troost - UNIX Systems | At Work: [email protected] |
| Investment Management Svcs, Inc. | At Play: [email protected] |
| 12 East 49th Street, 35th floor | Phone: (212) 339-2823 |
| New York, New York 10017 | Fax: (212) 339-2854 |
o===============================================================o
-- IMS is unlikely to share any of the above opinions --
-----------[000089][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Oct 1993 13:15:50 GMT From: [email protected] (Ian Heavens) To: comp.protocols.tcp-ip Subject: Re: Design of parallel TCP. Is it possible ?
Some more references on this subject, slanted towards multiprocessor STREAMS based TCP/IP. The work on the X kernel by Larry Peterson et al. is also crucial (the X kernel architecture seemed to get it right where Parallel Streams got it wrong). High Speed Protocol Implementations Based On A Multiprocessor Architecture Martina Zitterbat, University of Karlsruhe Proceedings of the IFIP WG 6.1/WG 6.4 International Workshop on Protocols for High Speed Networks Zurich, Switzerland May 1989 Multi-Processor Based High-Speed Communication Systems M. N. Jensen, M. Skov Technical University of Denmark, Lyngby 6th European Fibre Optic Communications and Local Area Networks Exposition Amsterdam, Netherlands June-July 1988 TCP/IP Networking using Transputers Roger Peel Department of Electronic and Electrical Engineering, University of Surrey, Guildford, U.K. Transputer Research and Applications 3 Amsterdam 1990 A Performance Analysis of Network I/O in Shared Memory Multiprocessors C. Thekkath, D. Eager E. Lazowska H. Levy Dept. of Computer Science and Engineering FR-35 University of Washington, Seattle, WA July 1992 Multithreading your STREAMS Device Driver in SunOS 5.0 Neal Nuckolls Internet Engineering, Sun Microsystems December 1991 A High Capacity TCP/IP in Parallel Streams Ken Dove Sequent Computer Systems UKUUG Summer 1990 Symmetric Multiprocessing in Solaris 2.0 S. Kleiman COMPCON San Francisco, California Spring 1992 Beyond Multiprocessing: Multithreading the SunOS Kernel USENIX Summer 1992 June 1992 J. R. Eykholt, S. R. Kleiman S. Barton, R. Faulkner, D. Stein, M. Smith, A. Shivalingiah, J. Voll, M. Weeks, D. Williams SunSoft, Inc. San Antonio, Texas The Parallelization of Mach/4.3BSD: Design Philosophy and Performance Analysis Joseph Boykin, Alan Langerman Encore Computer Corporation Symposium on Experiences with Distributed and Multiprocessor Systems (SEDMS I) October 1989 Experiences In Parallelisation of Streams-based Communications Drivers Ian Heavens Spider Software OpenForum Conference on Distributed Systems November 1992 ian --- Ian Heavens [email protected] Spider Software Spider Park, Stanwell Street Edinburgh, EH6 5NG, Scotland +44 31 555 5166 (Ext 4735) --
-----------[000090][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 1993 14:24:33 GMT From: [email protected] (Scott Larsen) To: comp.protocols.tcp-ip Subject: Re: Is NIC running out of unique IP addresses?
In article <[email protected]>,
Tim Wynn <[email protected]> wrote:
> One of my co-workers is in a UNIX course on TCP/IP right
>now, and he tells me that his instructor said that NIC is running
>out of unique IP addresses. Because of this, he says, NIC is
>calling people to ask for any unused addresses they might have
>requested in the past. Furthermore he said, it's next to impossible
>to get contiguous blocks of addresses anymore, and getting any
>addresses takes 6 weeks or more.
Not true. 3 weeks ago I requested 6 type "C" addresses and they are
contiguous. They arrived in about 3 days.
By the way, addresses are no longer given out by the DDN/NIC. Here's the
header to the reply from my latest address request:
*****************************************************************************
Please be advised that the DDN NIC ([email protected]) no longer
provides NIC services to the INTERNET. Registration services for the
INTERNET have been directed to the INTERNIC as of April 2, 1993.
E-Mail regarding INTERNET transactions must be directed to
[email protected] Phone questions can be directed to
1-800-444-4345 or if outside the continental U.S.A. then call
(619) 455-4600.
Please direct your attached request to [email protected] and/or
call the numbers listed above.
THE DDN/NIC STAFF
*****************************************************************************
> Is there any truth to any of this? It sounds absurd to me,
>but I don't know enough to confirm or refute it. It would seem that
>this situation would be so serious that I would have heard about it
>by now. Does anybody know the truth? I'm having this co-worker
>place a call to NIC to find out.
Grinding some numbers from my /etc/networks file (93/08/01) I see:
Network type Range # of type # in use % Capacity
--------------- --------------- --------------- --------------- ----------
A 1-126 126 51 40.5%
B 128-191 16,384 7509 45.8%
C 191-223 2,162,688 40,706 01.9%
(These numbers are already out of date, as numbers have been given out
since Aug. 1'st, and I'm sure that I introduced some 1-off errors in the
calculations, due to missing some restricted addresses and such.)
So you can see that there are _PLENTY_ of class "C" addresses available.
In addition, the current class "B" listings stopped at 167.167.0.0, and the
class "C" listings stopped at 202.20.79.0, so you can still get contiguous
blocks of addresses.
However, address depletion is a serious issue. According to "Supernetting:
an Address Assignment and Aggregation Strategy", by V. Fuller, T. Li, J. Yu,
and K. Varadham, all class "B" addresses could be exhausted within the next
15 months, if the present rate of growth is maintained. In exchange, large
quantities of class "C" addresses are being given out to avoid this. This,
though, puts a larger load on routers, as they have larger tables to maintain.
Current research is being done by the ROAD (Routing and Addressing) group of
the IETF (Internet Engineering Task Force).
I highly recommend the book "TCP/IP Network Administration", by Craig Hunt,
published by O'Reilly & Associates ($29.95). Most of the information here is
contained in this wonderful tome.
Scott Larsen
[email protected] UUCP: hplabs!hp-pcd!orstcs!larsen
--------------------------------------------------------------------------
"Grasshopper, look beyond the game, as you look beneath the surface of the
pool to see its depths."
- Master Po
-----------[000091][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Oct 1993 14:55:01 GMT From: [email protected] (O.P.P) To: comp.protocols.tcp-ip Subject: Re: Ftp script
In article <[email protected]>, [email protected] (O.P.P) writes:
|> In article <[email protected]>, [email protected] (Damoder Donur) writes:
|> |> Hello tcp-ip experts:
|> |>
|> |> i would like to know is there any ftp script that I can put into
|> |> cron file to get the file from the pc which is connected to network.
|> |>
|> |> I am administering Rs/6000 servers running AIX(3.2) and also running tcp-ip
|> |> using ethernet interface.
|> |>
|> |> Everyday I am manually ftping to pc getting some files. So instead of
|> |> doing manually is there any script which will automaticall connect to that pc
|> |> and get the file from pc to rs/6000.
|> |>
|> |> Thanks
|> |>
|> |> Damoder Donur
|> |> System Administrator
|> |>
|> |>
|> |> email Address:
|> |>
|> |> [email protected]
|> |> -------------------------------------------------------------
|> One way would be to add the following to a script
|>
|> ------------------start here-----------------
|> (
|> echo user username passwd
|> echo cd d:\data
|> echo get data.dat /usr/tmp/pc/data
|> echo quit
|> ) ftp -n ibmpc > /dev/null
^
add the pipe symbol | (curse vi it ate it....)
so.......
) | ftp -n ibmpc > /dev/null
o.p.p.
-----------[000092][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Oct 1993 16:37:56 GMT From: [email protected] (Ed Brill) To: comp.protocols.tcp-ip Subject: U.S. Robotics announces the addition of SNMP management to Total Control internetworking products
The following is a new product announcement from U.S. Robotics. The consenus
of the net was that product announcements of this form were acceptable and
desirable postings, so here goes.
Inquiries should be directed to 1-800-DIAL-USR or +1-708-982-5001. The
USR Systems Products Sales group does not presently maintain an e-mail
address, though I would be happy to forward electronic inquiries to them.
--Ed
-------------------------------------------------------------------------------
SKOKIE, Ill., -- October 6, 1993 -- U.S. Robotics, Inc., today
announced the addition of Simple Network Management Protocol (SNMP) to
its line of Total Control internetworking products. With U.S.
Robotics' Total Control Manager, network administrators can easily
access and manage their network from a single console. Total Control
Manager will ship in October.
Total Control Manager can be added to both the Enterprise Network Hub
and the Transaction Processing Hub. These complete, one-vendor
solutions solve the problem of network integration by combining X.25
PADs, modems, terminal servers, CSU/DSUs, and network interfaces into
one centrally managed chassis.
The Enterprise Network Hub enables organizations with remote locations
to aggregate their dial traffic onto T1 lines and route it through a
packet-switched network to their host computer at a central site.
The Transaction Processing Hub reduces verification times for credit
card, point-of-sale, and inquiry/response transaction processing
applications by interfacing with the local exchange carriers'
services, including Feature Group B, D and 800 lines and routing
traffic via T1 trunks to LAN interfaces.
"SNMP has really become the de facto management standard in the
industry," said Jonathan Zakin, U.S. Robotics executive vice president
of sales and marketing. "By incorporating it into the Total Control
products, we no longer add to the number of management consoles on the
network. With SNMP, we become part of the solution of the future."
For Baxter Healthcare Corp., a Total Control customer since 1991, SNMP
is a feature it is eager to have. "We have a goal at Baxter to
completely automate the entire network's recovery and operation," said
Steve Tindall, project leader of Baxter's telecommunications group.
"This is a long way off, but industry standards incorporated in
a single network platform are one way this goal will be accomplished.
With SNMP we can watch most of the network, and since Total Control
will now have SNMP, we're one step closer to our goal."
Customers can purchase U.S. Robotics' Total Control Manager with
Novell's Netware Management Platform for $3999. For those networks
already using the Novell Netware Management Platform, the cost is
$2059.
U.S. Robotics will also provide MIB extensions for customers using
packages like HP Openview, SunNet Manager, and Netview 6000 so Total
Control can be easily added to these management programs. These MIB
extensions will also be available via Internet.
The Enterprise Network Hub and Transaction Processing Hub are a
logical extension of the company's Total Control product line. U.S.
Robotics' Total Control line of intelligent management systems,
introduced in 1990, was the company's first entry into this market.
Both products use a common architecture, which consists of a 1 Gbps
backplane, andcircuit and packet-switched buses to minimize processing
time. Through downloadable software-defined technology, U.S. Robotics
can easily modify and enhance its products to take advantage of new
and emerging technologies.
U.S. Robotics, Inc., (NASDAQ:USRX), is a leading designer,manufacturer
and marketer of data communications systems and products. Both
corporate headquarters and manufacturing operations are based in
Skokie, Illinois. U.S. Robotics owns and operates U.S. Robotics Ltd.
in Slough, England, U.S. Robotics, s.a. in Lille, France and P.N.B.,
s.a. based in Suresnes, France. The company markets its products to
business, industry, government agencies and original equipment
manufacturers.
# # # # #
/98
All products mentioned are trademarks or registered trademarks of
their respective manufacturers.
-----------[000093][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Oct 1993 16:50:46 GMT From: [email protected] (Mike Bloom) To: comp.protocols.tcp-ip Subject: tcp/ip over token ring
I'd appreciate any feedback on porting a tcp/ip stack which runs over ethernet to also run over token ring. We have a standalone print server box that supports several streams-based protocol stacks over ethernet via DLPI. We're interested in porting tcp/ip (minimally) to be able to run over token ring. We already have a token ring driver and associated hardware for our platform, so all we're really interested in learning here is what "gotchas" we can expect when tcp and udp are running over token ring instead of ethernet. For example, are there any new routing issues which need to address, will arp and rarp still work, how does a diskless workstation learn about its IP address when running over token ring, ...... Thanks in advance for any help! Mike Bloom, Digital Products, Inc.
-----------[000094][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 93 17:26:05 GMT From: [email protected] (Thierry Turletti) To: comp.protocols.tcp-ip Subject: Re: audio conferencing software - mbone
In article <[email protected]>, [email protected] (Randy Turner) writes:
|>
|> I am looking for the software that allows internet-wide
|> audio conferencing between <n> numbered audio-capable
|> workstations...Recently I heard that it was on one of
|> the machines in the lbl.gov domain but I forgot which one.
|>
|> Also, I believe I will also need the SunOS 4.1 kernel
|> patches to support IP Multicast. Does anyone know where
|> these patches are and possibly provide some quick procedure
|> for building the kernel with these new changes ?
|>
|> Thanks!
|> Randy
Here is the list of the audio/videoconferencing tools available in the
public domain. Multicast IP extensions are freely available by anonymous
ftp from gregorio.stanford.edu in the "vmtp-ip" directory.
Regards,
Thierry
*********************************
AUDIO AND VIDEOCONFERENCING TOOLS
*********************************
* CU-SeeMe (0.40v)
------------------
- From: Cornell University
- Platform: Apple Macintosh
- Description: Videoconferencing software for Apple MAC
over IP. Requires SuperMac VideoSpigot board, Quicktime and
SpigotVDIG extensions added to the system for video transmission.
- Ftp-site: gated.cornell.edu:/pub/video
- Further information: Dick Cogger ([email protected])
- Sources: not available.
* IVS (3.2v)
------------
- From: INRIA Sophia Antipolis - RODEO Project.
- Platforms: Sun Sparc station + VideoPix or Parallax framegrabber.
HP station + Raster Rops framegrabber.
Silicon Graphics station + Indigo framegrabber.
DEC station + VIDEOTX framegrabber
- Description: Audio/video-conferencing tool which supports both
point-to-point and broadcasting of audio/video using multicast IP.
- Audio encoding:
+ PCM 64kb/s 8-bits u-law encoded 8KHz PCM (G.711)
+ DVI ADPCM 32 kb/s
+ Variable ADPCM (ADPCM + Huffman encoding) (10-30kb/s)
- Video encoding: (H.261) variable rate. Three formats available:
+ SCIF (704x576 pixels)
+ CIF (352x288 pixels)
+ QCIF (176x144 pixels)
- Ftp-site: zenon.inria.fr:rodeo/ivs
- Further information: Thierry Turletti ([email protected])
- Standards: IP Multicast, G.711, H.261.
- Sources: available.
* NEVOT (1.4v)
--------------
- From: AT&T BL
- Platforms: Sun Sparc Station (SunOS 4.1.x)
Silicon Graphics
- Description: Audio-conferencing tool which supports both
point-to-point and broadcasting of audio using multicast IP.
- Audio encoding:
+ PCM 64kb/s 8-bits u-law encoded 8KHz PCM (G.711)
+ ADPCM 32 kb/s [Sun only] (G.721)
+ DVI ADPCM 32 kb/s
+ ADPCM 24 kb/s [Sun only] (G.723)
+ CELP 4.8 kb/s
+ LPC 2.4 kb/s
- Ftp-site: gaia.cs.umass.edu:pub/nevot
- Further information: Henning Schulzrinne ([email protected])
- Standards: IP Multicast, G.711, G.721, G.723, GSM.
- Sources: available.
* NV (3.2v)
-----------
- From: XEROX/PARC
- Platforms: Sun Sparc station + VideoPix framegrabber.
SGI Indigo station + Indigo video framegrabber.
DEC station + DEC PIP and DEC JVideo framegrabbers.
Sony NEWS video capture support.
- Description: Video-conferencing tool which supports both
point-to-point and broadcasting of video using multicast IP.
- Video encoding: Variable rate. Video format is
320x240 pixels for NTSC sources and 384x288 pixels for PAL sources.
- Ftp-site: parcftp.xerox.com:/pub/net-research
- Further information: Ron Frederick ([email protected])
- Standards: IP Multicast
- Sources: available.
* VAT (2.14v)
-------------
- From: Lawrence Berkeley Laboratory
- Platforms: SUN SPARC station
SGI station
DEC station
- Description: Audio-conferencing tool which supports both
point-to-point and broadcasting of audio using multicast IP.
- Audio encoding:
+ PCM 64kb/s 8-bits u-law encoded 8KHz PCM
+ IDVI 32 Kb/s Intel DVI ADPCM
+ GSM 16 Kb/s
+ LPC1 18kb/s Linear Predictive Coder
+ LPC2 8Kb/s Linear Predictive Coder
- Ftp-site: ftp.ee.lbl.gov
- Further information: Van Jacobson ([email protected])
- Standards: IP Multicast
- Sources: not available.
**********************
SESSION DIRECTORY TOOL
**********************
* SD (1.14v)
------------
- From: Lawrence Berkeley Laboratory
- Platforms: SUN SPARC station
SGI station
DEC station
- Description: Session director. SD lists all the
audio/video conferences available on the Internet.
Information about each conference is presented to the user.
- Ftp-site: ftp.ee.lbl.gov
- Standards: IP Multicast
- Further information: Van Jacobson ([email protected])
- Standards: IP Multicast
- Sources: not available.
--
Thierry Turletti - Project RODEO - INRIA sophia-Antipolis -FRANCE
e-mail: [email protected]
ivs-talk-site: jerry.inria.fr
-----------[000095][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Oct 1993 18:32:43 GMT From: [email protected] (David Maynard) To: comp.protocols.tcp-ip Subject: Re: Is NIC running out of unique IP addresses?
In article <[email protected]> [email protected] (Tim Wynn) writes: > One of my co-workers is in a UNIX course on TCP/IP right >now, and he tells me that his instructor said that NIC is running >out of unique IP addresses. Because of this, he says, NIC is >calling people to ask for any unused addresses they might have >requested in the past. Furthermore he said, it's next to impossible >to get contiguous blocks of addresses anymore, and getting any >addresses takes 6 weeks or more. The only potential shortage is "Class B" addresses for sites that want a single network with more that ~254 hosts. If someone thinks they need a B network, they might have to spend awhile convincing INTERNIC that they really need it (as opposed to multiple Class C nets). As mentioned in another response, people are working on long-term solutions. It sounds like the vast majority of your customers will just need Class C networks. There shouldn't be any problem or any delay in obtaining them. I got a new C network number a few weeks ago. I emailed the request one evening and had a network number before noon the next day. I was impressed! -David -- David P. Maynard, Carnegie Mellon University & Dependable Solutions USMail: 14312 Richard Walker Blvd, Austin, TX 78728-6862 EMail: [email protected], Tel: +1 512 251 8122, Fax: +1 512 251 8308
-----------[000096][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Oct 1993 19:30:19 GMT From: Boris Yanovsky <[email protected]> To: comp.sys.apollo,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: HELP: RJ45 to BNC conversion, how do I do it?
In article <[email protected]>, <[email protected]> writes: > What we have is an RJ45 cable that runs between the two machines, but there > is no way to connect the RJ45 cable to the Apollo w/ the BNC connector. Even if you get the converter just runing an RJ45 cable between 2 machines will not work. You need a 10Base-T concentrator. ***************************************************** Boris Yanovsky Phone: (408) 973-7171 NetManage Inc. Fax: (408) 257-6405 20823 Stevens Creek Blvd. Internet: [email protected] Cupertino, California, U.S.A. *****************************************************
-----------[000097][next][prev][last][first]---------------------------------------------------- Date: 6 Oct 1993 19:46:08 GMT From: [email protected] (Tony Li) To: comp.protocols.tcp-ip Subject: Re: ARP entry timeouts
In article <[email protected]> "Kenneth Chin"
<[email protected]> writes:
I'm just curious about what the standard ARP cache entry timeout
may be for routers when they're performing proxy-arp'ing? In
most cases, I believe that this is configurable, but what do people
usually set it at?
For a cisco router, the timeout is 4 hrs. The vast majority of people
(>>99%) don't configure the timeout any lower.
Tony
-----------[000098][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Oct 1993 19:50:55 GMT From: [email protected] (Jym Barnes) To: comp.protocols.tcp-ip,vmsnet.networks.tcp-ip.misc Subject: Configuration for SLIP on terminal server
Hi, Does anyone have the port configuration for a DECServer 300 offering a SLIP service. Are you using any flow control? If you could send me the sho port output you would make my day. If you could also send the modems setup. I will probably being using this port in DYNAMIC mode. This way I could utilize present outgoing modems. Does anyone know if the DECServer 300 supports compressed headers? Please reply to [email protected] Thanks, -Jym-
-----------[000099][next][prev][last][first]---------------------------------------------------- Date: Wed, 6 Oct 1993 23:08:36 GMT From: [email protected] (Ran Atkinson) To: comp.protocols.tcp-ip Subject: Re: Network Time
In article <[email protected]> [email protected] (Amos Shapira) writes: % Does anyone have experience in running xntp3 in a "broadcast-client" mode? % It doesn't work for me. In article <[email protected]> [email protected] (Rens Troost) writes: >What breaks? We're running it in that mode here, and it works fine. I >must ssay it makes life a whole lot easier in a dynamic environment. Older versions of the xntp3 software didn't work quite right in broadcast mode on some systems. Newer versions of the xntp3 work fine. Perhaps Amos Shapira doesn't have the latest and greatest version of xntp3 ? Followups are directed to comp.protocols.time.ntp since this is really an NTP discussion.
-----------[000100][next][prev][last][first]---------------------------------------------------- Date: Thu, 07 Oct 1993 13:02:20 -0800 From: [email protected] (Brian Coughlin) To: comp.protocols.tcp-ip Subject: Re: TCP/IP over VSAT
In article <[email protected]>, [email protected] (Bryan E. Miller) wrote: > > Has anyone out there successfully (or unsuccessfully) attempted > running IP-based applications over VSAT technology? If so, > could you briefly describe your setup and application. > > Thanks, > > Bryan We've done it here at PBS. We've used/tested 2 VSAT vendors' products, AT&T Tridom and Hughes. The are 2 main issues with VSAT and TCP/IP: 1) propagation delay and it's effect on performance 2) IP traffic gatewaying/filtering, to minimize extraneous IP traffic over the VSAT spacelink For #2, AT&T built an IP router into their VSAT equipment, whereas Hughes uses packet-type and MAC address filtering. For #1, you have to make sure that TCP window size is set large enough to reduce idle time of a sender waiting for an ACK to get back from the receiver before they can resume transmitting packets. This is due to the large propogation delay of the connection having to "hop" 23000 miles up and back to bounce off of the satellite. Furthermore, all point-to-point traffic must go through what's called the VSAT hub site. So, if neither of the hosts talking to each other are on the hub, the delay doubles becuase the connection requires 4 "hops" instead of 2. As for running real applications, avoid ones like telnet in which each character may need to be echoed back from host to remote. PBS plans to run mainly batched oriented traffic over VSAT to make for more optimal usage of a VSAT's bandwidth. Our setup is in flux right now, so I'll have to get back to you on that if you want more details .... Brian
-----------[000101][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 00:22:43 GMT From: [email protected] (Louis Todd Heberlein) To: comp.protocols.tcp-ip Subject: ICMP dropping options for IP
Hi,
I have been trying to develop an alternate traceroute
program, but I am having trouble with the design.
The design goes as follows:
Like traceroute, I send a packet to an unknown port on the
destination host.
Unlike traceroute, I have turned on the record route option in
the IP header.
What I think SHOULD happen is the remote machine returns an ICMP
error message which should include the IP header of my
probe packet and therefore, the recorded route. Thus, I
would have a single probe version of traceroute.
Unfortunately, the IP header returned inside the ICMP message is marked
with a header length of only 20 bytes; the minumum for the IP header.
All my IP options and recorded route are missing.
Does anyone know why ICMP does not include options in the IP header
that is returned?
Thanks,
Todd [email protected]
-----------[000102][next][prev][last][first]---------------------------------------------------- Date: 7 Oct 1993 00:49:19 GMT From: [email protected] (Henry Choy) To: comp.protocols.tcp-ip,sci.research Subject: Info is so scattered!
I was trying to interpret my IP header, which was transmitted on
ethernet. How can I ever find information that talks about both
subjects? One of my resources is the rfc's. The IP protocol standard
is discussed in rfc x. I manually searched for occurrences of
"ethernet" and "header" in x, which leads me to a set of rfcs.
Finally I find an rfc that tells me what is happening.
--
Henry Choy
[email protected]
Anything worth doing is worth overdoing. - R. Heinlein
is worth doing well. - Philip Dormer Stanhope, Earl of Chesterfield
-----------[000103][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 01:42:31 GMT From: [email protected] (Ben A. Mesander) To: comp.protocols.tcp-ip Subject: Broadcast RPC
Hello, While developing an RPC/UDP application, I thought it would be more efficient to contact rpc daemons on my local network with broadcast RPC, rather than calling each host in turn. It would seem that if the number of hosts is n, then calling each host would result in 2n udp packets for every call (barring complications), while a broadcast scheme would involve n+1 packets - one for the broadcast, and n replies. However, I see that every host is responding to a clnt_broadcast() call four times, so I see 4n+1 packets. I have verified that the RPC libraries in SunOS 4.1.3 and DG/UX 5.4.1 both do this. The source to clnt_broadcast() looked opaque to me, so I used etherfind to sniff rpc/udp on my network. When I make a clnt_broadcast() call, the rpc client sends out four, rather than one broadcast packet. Is this a bug? -- [email protected]
-----------[000104][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 02:08:00 GMT From: [email protected] (Vanessa Gibb x7289) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Wollongong and SCO ODT 2.0
In article <[email protected]> [email protected] (Scott Neugroschl) writes: >Hi. I'm running SCO ODT 2.0 as an LPD server. On another 486 PC, >I'm running Wollongong Pathway Access and Pathway Client NFS. The Network >Driver for Windows installed. We have an HP LJ4 hooked up to the ODT system. > >When we print from Windows to the LJ4 over the net, we get garbage on the >printout. I believe it is because there is no way to pass the -oraw option >to the SCO spooler. > >I would like to know if anyone else is using this sort of configuration, >and if so, if they have gotten this to work. > >Thanks > >-- >Scott "The Pseudo-Hacker" Neugroschl >-- Beat me, Whip me, make me code in Ada Scott, There are a couple of things that you should check: Firstly, assuming that you are using LPRINT to print, make sure that you are using the -Os option (with LPRQ). When this option is used, the file to be printed will be sent as postscript. Secondly, (a long shot :-)), ensure that the printer supports postscript - if it does not, the file would print as garbage. If neither of these suggestions help, please contact Wollongong Product Support on 415-962-7140. We will be happy to run through your setup and debug your printing problems. Thanks, Vanessa G. Gibb The Wollongong Group, Inc.
-----------[000105][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 02:09:15 GMT From: [email protected] (Carsten Tschach) To: comp.protocols.tcp-ip Subject: Using PC as Terminal/Printer-Server ?
Hi, I'm looking vor a software that let a PC act like a terminal-server. The PC hast no other function, therefor I don't need any slow TSR's. First of all I want to use the two parallel ports to connect to the printers and than maybe connect modems to the serial port. It would also be great if you can log into the 'PC-Terminal-Server' and do the administative things or use the modem for dialouts. The PC I currently use is a 286-16 with a wd8003 ethernet-card and a boopd- bootprom. Please send any responses to: [email protected] Bye, Carsten -- / Carsten Tschach [email protected] [email protected] \ | | | Du sollst Dir den Kopf nicht nach Frauen verdrehen, die zu alt UND zu | \ huebsch fuer Dich sind. (Boris Kemp) /
-----------[000106][next][prev][last][first]---------------------------------------------------- Date: 7 Oct 1993 03:58:07 GMT From: [email protected] (Samson Chen) To: comp.protocols.tcp-ip Subject: yyparse()???
Hello everybody, I'd like to thank all the guys who answered my question here. Now I know how to use select() to do I/O multiplexing. I should study harder. It is detail on Steven's book. I have another little problem. When I read the source of FTPD (wu-ftpd, Washington University), I found there is an infinite loop yyparse() at the last statement of main(). But I cannot find its real source. I can neither find it on system call. Just now, I saw yyparse() again on the source of Berkeley BIND. I will be very appreciate if someone can tell me where to find the real body of yyparse(). Thanks to all. Samson Chen [email protected] Chung-Hua Polytechnic Institute, Hsin-Chu, Taiwan /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
-----------[000107][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 05:22:51 GMT From: [email protected] (Tom Fitzgerald) To: comp.protocols.tcp-ip Subject: timed vs. NTP (was: Specifying IP)
> >Even with timed, you have to set -M on at least one of the systems.... [email protected] (Vernon Schryver) writes: > NO! NO! NO! EACH AND EVERY TIMED SHOULD BE RUNNING WITH -M EVERYWHERE! > Sorry, but I've heard and fought that nonsense so many times that > it is very painful. We're going to disagree violently on this one, then. I want -M on one, maybe two systems so that I can synch those systems and push the fixed date out with rdate. Before we got Internet access, we (like lots of sites) did this by having the timed master dialup to the NIST. Even better, now I have systems here running both NTP and F.F. Jacot Guillarmod's timed+ntp which broadcasts timed updates from a server which is set via NTP - this lets me mix NTP and timed on a single net, in synch. But, one specific system must be the timed master. I suspect that many people agree with me - SCO ODT 1.0 was shipped with -M as the default, and I think SCO got so much grief for this that they changed the default to non-M and have left it there in all later versions. Many admins, including me, wasted hours going around to hundreds of systems stomping out the -Ms. And in this case, I don't think it's relevant that the vast majority of non-Internet-connected users don't care if their clocks are off by a few minutes. Defaulting to -M optimizes for people who don't care if their clocks are wrong, with a heavy penalty for those of us who want to get it right. Actually.... did you change timed so that "date <new-time> ; rdate" works on systems other than the master? That's only a partial fix, but it's far better than not having it at all. > About only the reason to turn off -M is > to mess up time in a network, although the perpetrators usually do not > realize or acknowledge as much. The reason is to set timed's idea of the time to something better than just the average of a bunch of unreliable sysems. > I have heard claims that NTP uses far more CPU cycles than a point-to-point > hack named "timeslave", which uses ICMP timestamps, the UDP time port, > and lots of naive filtering to ride even intermittently asymmetrically > loaded low speed links. It might be more expensive than a simpler scheme, but at less than 4 CPU seconds/day, I consider NTP a bargain. I do regret the 100 KB of resident memory, tho. -- Tom Fitzgerald Wang Labs, Lowell MA, USA [email protected] 1-508-967-5278
-----------[000108][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 12:50:58 From: [email protected] (Tom Billingsley) To: comp.protocols.tcp-ip Subject: CNE Study Group
I am looking for a newsgroup that has some focus on people who are working on the CNE tests. Is there such a group or possibly a related group. Thx in advance TDB
-----------[000109][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 08:30:21 GMT From: [email protected] (Carsten Tschach) To: comp.protocols.tcp-ip Subject: Using PC as Terminal/Printer-Server ?
Hi, I'm looking vor a software that let a PC act like a terminal-server. The PC hast no other function, therefor I don't need any slow TSR's. First of all I want to use the two parallel ports to connect to the printers and than maybe connect modems to the serial port. It would also be great if you can log into the 'PC-Terminal-Server' and do the administative things or use the modem for dialouts. The PC I currently use is a 286-16 with a wd8003 ethernet-card and a boopd- bootprom. Please send any responses to: [email protected] Bye, Carsten -- / Carsten Tschach [email protected] [email protected] \ | | | Du sollst Dir den Kopf nicht nach Frauen verdrehen, die zu alt UND zu | \ huebsch fuer Dich sind. (Boris Kemp) /
-----------[000110][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 09:35:48 GMT From: [email protected] (Peter Rindfuss) To: comp.protocols.tcp-ip Subject: How to SLIP away?
I successfully set up cslip-2.6 on our Sun and can connect to it from my home MSDOS PC. Now I wonder whether and how I can use this interface to attach to other computers than the Sun (which has the modem). I assume that I have to define some routing information, but I don't have enough Unix experience to figure it out myself. Peter Rindfuss (Wissenschaftszentrum Berlin)
-----------[000111][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 11:30:41 GMT From: [email protected] (E.J.Leoni-Smith) To: comp.sys.apollo,comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: HELP: RJ45 to BNC conversion, how do I do it?
In article <[email protected]> Boris Yanovsky <[email protected]> writes: > >In article <[email protected]>, <[email protected]> writes: > >> What we have is an RJ45 cable that runs between the two machines, but there >> is no way to connect the RJ45 cable to the Apollo w/ the BNC connector. >Even if you get the converter just runing an RJ45 cable between 2 machines >will not work. You need a 10Base-T concentrator. > You can buy a thin-to-10baseT transciever: These are around 200 UK pounds here - my guess is $200 us. Leo
-----------[000112][next][prev][last][first]---------------------------------------------------- Date: 7 Oct 1993 12:14:14 GMT From: Paul.Terray,,,[email protected] (Paul Terray) To: comp.protocols.tcp-ip Subject: Re: yyparse()???
Hi, yyparse is, like any function starting with yy, either a lex or a yacc function. Lex and Yacc are two parser generator stantdard in C. You could probably find the description of your parser in a file ending in .y (If I remember well, yyparse is generated by yacc). For any other information, read the manual pages for lex and yacc. Paul
-----------[000113][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 12:49:51 GMT From: [email protected] (John Hascall) To: comp.protocols.tcp-ip Subject: Re: yyparse()???
[email protected] writes: } I have another little problem. When I read the source of FTPD }(wu-ftpd, Washington University), I found there is an infinite loop }yyparse() at the last statement of main(). But I cannot find its real }source. I can neither find it on system call. Just now, I saw yyparse() }again on the source of Berkeley BIND. I will be very appreciate if someone }can tell me where to find the real body of yyparse(). Thanks to all. If it is like other ftp daemons I have seen there is a file called ftpcmd.y which is run through a program called yacc to generate C code. If you look through all the code, you will no doubt find a call to exit(). John -- John Hascall ``An ill-chosen word is the fool's messenger.'' Systems Software Engineer Project Vincent Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
-----------[000114][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 12:53:30 GMT From: [email protected] (Arjan Kenter) To: comp.protocols.tcp-ip Subject: Re: yyparse()???
In article <[email protected]>, [email protected] (Samson Chen)
writes:
> Hello everybody,
> I'd like to thank all the guys who answered my question here. Now I
> know how to use select() to do I/O multiplexing. I should study harder. It
> is detail on Steven's book.
> I have another little problem. When I read the source of FTPD
> (wu-ftpd, Washington University), I found there is an infinite loop
> yyparse() at the last statement of main(). But I cannot find its real
> source. I can neither find it on system call. Just now, I saw yyparse()
> again on the source of Berkeley BIND. I will be very appreciate if someone
> can tell me where to find the real body of yyparse(). Thanks to all.
>
> Samson Chen
> [email protected]
> Chung-Hua Polytechnic Institute, Hsin-Chu, Taiwan
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
yyparse() is never the same thing... It's the parser function that yacc
(Yet Another Compiler Compiler) produces from an LR(1) grammar. On Unix
systems yacc (or its Gnu counterpart) is very often used to implement
computer (programming/specification) languages. In fact, the function yyparse()
_is_ always the same, the difference is in the parsing tables. If you want
the code, it is usually in /usr/lib/yaccpar (on my Sun: /usr/ccs/bin/yaccpar).
Otherwise, the man page on yacc may tell you where to find it.
I think it is enough for you to know that yyparse() implements a parser, but
if you are interested, browse through some books on compiler writing.
Regards,
Arjan Kenter
---
___
__/ \__________
| \___/ | ir. H.J.H.N. Kenter [email protected]
|___ _ __ ___ | University of Twente tel. +31 53 893747
| | | / \ (__ | Tele-Informatics & Open Systems tfx. +31 53 333815
| | | \__/ ___) | P.O. Box 217 7500 AE Enschede
|_________________| The Netherlands
I can make it all worthwhile... as a Rock 'n Roll star --- David Bowie
-----------[000115][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 15:14:49 GMT From: [email protected] (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: timed vs. NTP (was: Specifying IP)
In article <[email protected]> [email protected] (Tom Fitzgerald) writes: >> >Even with timed, you have to set -M on at least one of the systems.... > >[email protected] (Vernon Schryver) writes: > >> NO! NO! NO! EACH AND EVERY TIMED SHOULD BE RUNNING WITH -M EVERYWHERE! >> Sorry, but I've heard and fought that nonsense so many times that >> it is very painful. > >We're going to disagree violently on this one, then. I want -M on one, >maybe two systems so that I can synch those systems and push the fixed date >out with rdate. Before we got Internet access, we (like lots of sites) did >this by having the timed master dialup to the NIST. Even better, now I >have systems here running both NTP and F.F. Jacot Guillarmod's timed+ntp >which broadcasts timed updates from a server which is set via NTP - this >lets me mix NTP and timed on a single net, in synch. But, one specific >system must be the timed master. You are simply wrong, in the company of many other people. -M does not mean "master" to the 4.*BSD timed. Turning off -M on machines that have bad clocks or open root accounts does not improve time in your system. With the 4.3BSD timed as well as its descendents, the `date` command on any system sends the desired change to the current "moderator" (miss-named "master"), which blithely changes its clock and sends corrections to all other participating systems. This part of the protocol lacks any consideration for authentication, although it is possible to hack in some simple authorization checks into the code as I did for 4.4BSD. The so called master averages the clocks of all participating systems, including those without -M, no matter how bad their crystals. Read the code. Specifically, notice that -M only affects the Mflag variable, and then look at the 13 places where Mflag is used. Notice in master.c that measure() is called for all systems, and that later in networkdelta() is called to average all of the ticks, no matter how bad. (The 4.3BSD code simply computed the arithmetic average after excluding obvious bogons. I changed it to compute the median, and made it a much faster besides.) Timed was a master's degree project by some Berkeley students. It was clearly intended for a very few commonly administrated VAX's on a single ethernet. As such, they did not really think through nor implement the implications of real "non-master" machines. Their hooks for gateways in the code and the protocol were wrong. My -F and -G additions fix the trustworthy systems problem, and fix gateway problems at the cost of administrative hassles. Of course, there are other glaring errors in the protocol, but with -F/-G it works well enough. >I suspect that many people agree with me - SCO ODT 1.0 was shipped with -M >as the default, and I think SCO got so much grief for this that they >changed the default to non-M and have left it there in all later versions. >Many admins, including me, wasted hours going around to hundreds of systems >stomping out the -Ms. I wouldn't be surprised if SCO changed their minds, but it would be due to uninformed complaints and misunderstandings. You and others indeed waste hours going to hundreds of systems stomping out -Ms, because you did yourself only harm. You did not exclude the bad ticks or untrusted `date` commands of those systems. You exclude those systems from being elected as moderators should your trusted systems die. -M does not really mean "master" to timed, despite the fact that the code and documentation uses the word "master". >And in this case, I don't think it's relevant that the vast majority of >non-Internet-connected users don't care if their clocks are off by a few >minutes. Defaulting to -M optimizes for people who don't care if their >clocks are wrong, with a heavy penalty for those of us who want to get it >right. Wrong. -M does not functionally mean "master". Turning off -M only reduces the stability of time in your network. >Actually.... did you change timed so that "date <new-time> ; rdate" works >on systems other than the master? That's only a partial fix, but it's far >better than not having it at all. Which `rdate` did you use? What did it do? `date newtime` should have always worked. In the system we've mentioned with the heavily changed timed, I introduced a bug in one release that hung on for a long time because of operating system release schedules. It has long since been fixed. The original 4.3BSD `date` command was changed to send a TSP message to the local timed daemon, which if it was not the current "master" (really moderator) would send the new time to the current "master" (really moderator) which would adjust its clock and forward the result to all machines including the originator where the `date` command ran. This mechanism is not and was not affected by -M on the local system, except that without -M you could be sure the current "master" (really moderator) is not the local system. Systems without -M are still able to change time in the entire system (unless you use -F or -G in the 4.4BSD version or unless your `timed` is otherwise changed). >> About only the reason to turn off -M is >> to mess up time in a network, although the perpetrators usually do not >> realize or acknowledge as much. > >The reason is to set timed's idea of the time to something better than just >the average of a bunch of unreliable sysems. Wrong. The unreliable time of all system, unreliable or not, is collected and averaged into the time redistributed by the so called master. Vernon Schryver [email protected]
-----------[000116][next][prev][last][first]---------------------------------------------------- Date: 7 Oct 1993 15:50:36 GMT From: [email protected] () To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: FTP PC/TCP 2.2, Windows 3.1 and remote printing
I have just recently installed the PC/TCP 2.2 software for DOS and Windows on a 486 machine. Everything seems to work fine except for remote printing. For several days I have been working on the problem, and have been trying to get through to someone at FTP without much luck. Remote printing under DOS seems to work fine using 'lpr' command. But when trying to access remote printers via windows apps, it just doesn't behave itself. I have gone through the setup procedure several times- under FTp Network Icon, then to printers, I setup a host:printer, username=nobody, type=pcnfs port=lpt2, then I connect, and everything seems to be OK. When I print I get several different results- the main one being that I get nothing, but I have another strange effect, The PC (Windows) will hang for about 30 seconds, and the speaker emits a click noise about every 5 seconds. I know this is sketchy but maybe there are some known problems. Thanks alot Stephen Hauskins UCSC
-----------[000117][next][prev][last][first]---------------------------------------------------- Date: 7 Oct 93 20:02:29 GMT From: [email protected] (Edward S. Reynolds) To: comp.protocols.tcp-ip Subject: BGP and Policy Routing
Perhaps someone in this group could answer some questions I have regarding policy-based routing and more specifically BGP. Can I use BGP to allow 2 organizations to share a common IP backbone with access to common resources yet prevent them from accessing each other. The configuration might be something like this. Networks A and B share a common backbone network C and have common access to resources in network D. Network C is a transit network and networks A, B and D are stub networks. Can BGP prevent A and B from accessing each other by limiting route advertisements in network C ? Is this secure or merely an inconvenience for a network hack ? That is, could someone in network B access network A via source-routing or some other scheme ? Can the border routers prevent this since they have no knowledge of each other ? I realize true and trusted security will require the use of Kerberos, RSA or other authentification and encryption methods. The intent here is to control the use of private network resources while providing a common transport backbone. Can BGP-3 handle this ?? BGP-4 ?? Thanks, Ed Reynolds ([email protected]) EDS Technology Architecture +-------------------------------------------------------------------------+ | DISCLAIMER: My comments are just that... Mine !!! | | And do not represent those of my employer or anyone else. | +-------------------------------------------------------------------------+
-----------[000118][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 21:16:56 GMT From: [email protected] (Scott VanArtsdalen) To: comp.protocols.tcp-ip Subject: Re: Subnet Addressing Summary
[email protected] (Dennis Coyle) writes:
( Text Deleted )
>RFC References: RFC1219, RFC1009, RFC950, RFC1122, RFC942
>Thanks to all that applied, I hope this helps out some other newbe :) !
Not really, I didn't catch the first part of this thread. |:^[
Can anyone tell me where I can get hold of these RFCs and some info
on subnetting in general? Sorry for the newbie-ish question but that's
what I am... ?:^]
--------------------------------------------------------------------------
\ /\ Aeronca 7AC Champ
\ /__\ =(*)= N3115E =(*)=
Scott \/an \rtsdalen "The Boonie Bouncer"
--------------------------------------------------------------------------
Opinions expressed here do not necessarily reflect those of
Lockheed Missiles & Space Co., Inc. or its management. =*
--------------------------------------------------------------------------
-----------[000119][next][prev][last][first]---------------------------------------------------- Date: Thu, 7 Oct 1993 21:47:59 GMT From: [email protected] (Mark Reardon) To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: Re: IP over VSAT network
In article <[email protected]>, [email protected] (Devin Cassas) writes: |> |> I have RS/6000s communicating over a Hughes VSAT network. The RS/6000s are |> running TCP/IP and the application is having problems with timeouts. Packets |> are always delivered reliably, but I'm not sure about the round trip time. |> PING gives me consistantly round trip times in the 3-7 second (yes thats |> SECONDS) range. |> |> My question is: does anybody have any experience or knowledge of tuning the |> TCP/IP protocol stack to make it work better over satellite network? |> |> If it helps, the IP is encapsulated in SNA at the earth station before it is |> beamed into space. |> |> Thank you for your help. |> |> Devin Cassas |> [email protected] I am a lead engineer on a competitive product, the AT&T Tridom Clearlink VSAT. There are differences between their product and ours (theirs is a bridge and ours is a Router). These differences may come into play but I can tell you about ours and you can apply that to your knowledge of your network and see if it makes sense. The RS/6000 at one of our customer sites is running FTP (TCP/IP based) and the ping times are in the 1 to 2 second range. That is from a VSAT to the Customers data center (one satellite hop). If your destination is on another VSAT then the double hop and switch decision would probably double that. So, the low end of your range seems reasonable and the high could be caused by congestion and queueing. The RS/6000 measures the round trip and computes a running average. Most use the formula srtt = (meas. rtt + (7 * srtt))/8. Twice this value is usually the time our value. In /usr/include/netinet there are header files that set the initial values and then the time out adjusts to the delay. As long as the delay doesn't double, no time out will occur. If it does, a retransmission will occur. My experience is that the RS/6000 worked well in our environment. Hope this helps (and that people at Hughes can help with any differences). -- _____________________________________________ Mark Reardon AT&T Tridom (404-514-3383) email: [email protected], attmail!tridom!mwr
-----------[000120][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 1993 07:08:44 -0400 From: [email protected] (Erik Heimdahl) To: comp.protocols.tcp-ip Subject: TCP/IP for Dos and Windows
Does anybody know if there are any _CHEAP_ TCP/IP implementations for Dos and Windows (PD or SW also welcome). I have to interface between both Dos- and Windows-applications and a UNIX application using Sockets. /erik PS. _Please_ awnser by _mail_, I don't get this newsgroup to my site. DS.
-----------[000121][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Oct 1993 08:48:25 From: [email protected] (Derek Brown) To: comp.protocols.tcp-ip Subject: Re: Broadcast RPC
>I think you loose here because the RPC servers are not all on the same
>port. The scenario you have (if I get RPC right) is as follows:
>1. The client broadcasts on the net to the portmappers (UDP port 111) asking
> on which port and which version is supported on the various hosts. (1
> packet).
>2. The client receieves replies from all the portmappers telling it what port
> to use in order to talk to your UDP server (n packets).
>3. The client starts talking to each server individually, because almost all
> of them sit on a different port broadcast isn't used here (another n
> packets sent and another n packets recived).
>That gives 3n+1 if I count it right, dunno where the other n packets came
>from, maybe the client asks the portmappers twice in case it lost some
>replys (that's what rup does, for instance).
>Maybe tcpview can give you more details about the packets.
>Hope this helps,
>--Amos
This isn't quite right... The way rpc broadcasts work is this:
1) The client broadcasts to port 111, so that the portmapper can hear it,
the portmapper is the only thing that a) the client knows about and b)
knows what port the servers are on.
2) When the portmapper receives the broadcast, it behaves as a proxy agent,
and makes the call to the intended server. The server replies to the
portmapper, and the portmapper sends the reply to the server.
This leaves you with 2n + 1 packets.
The reason you are seeing more is that the RPC code has a loop, in which
(at least in the original Sun RPC 4.0 code) would broadcast a total of 6 times,
increasing the timeout for the response each time. Also, each time a response
is received, the clnt_broadcast() calls a callback. This loop can be broken if
the callback returns false. There are two ways, then, of getting 2 responses
from the servers, or 4n+1 packets
1) Your library has been modified to only send out two broadcasts (rather
than six) to shorten the broadcast timeout.
2) Your callback is maintaining a list of addresses who have replied, and is
stopping when it receives a duplicate list.
Hope this helps,
dB
----------------------------------------------------
F Derek Brown
T [email protected]
P (415) 543-9001
Software (fax) 543-9002
-----------[000122][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 1993 16:24:45 -0600 From: hleal To: comp.protocols.tcp-ip Subject: Diferences using RPC with UDP and TCP?
Does anybody has some information about wich the diferences between UDP and TCP when using RPC protocol? Any information will be apreciatted. please send e-mail to: [email protected]
-----------[000123][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 93 12:48:00 From: [email protected] (Amos Shapira) To: comp.protocols.tcp-ip Subject: Re: Broadcast RPC
[email protected] (Ben A. Mesander) writes: |While developing an RPC/UDP application, I thought it would be more efficient |to contact rpc daemons on my local network with broadcast RPC, rather than |calling each host in turn. It would seem that if the number of hosts is n, |then calling each host would result in 2n udp packets for every call (barring |complications), while a broadcast scheme would involve n+1 packets - one for |the broadcast, and n replies. |However, I see that every host is responding to a clnt_broadcast() call four |times, so I see 4n+1 packets. I have verified that the RPC libraries in SunOS |4.1.3 and DG/UX 5.4.1 both do this. The source to clnt_broadcast() looked |opaque to me, so I used etherfind to sniff rpc/udp on my network. When I |make a clnt_broadcast() call, the rpc client sends out four, rather than |one broadcast packet. |Is this a bug? I think you loose here because the RPC servers are not all on the same port. The scenario you have (if I get RPC right) is as follows: 1. The client broadcasts on the net to the portmappers (UDP port 111) asking on which port and which version is supported on the various hosts. (1 packet). 2. The client receieves replies from all the portmappers telling it what port to use in order to talk to your UDP server (n packets). 3. The client starts talking to each server individually, because almost all of them sit on a different port broadcast isn't used here (another n packets sent and another n packets recived). That gives 3n+1 if I count it right, dunno where the other n packets came from, maybe the client asks the portmappers twice in case it lost some replys (that's what rup does, for instance). Maybe tcpview can give you more details about the packets. Hope this helps, --Amos -- --Amos Shapira (Jumper Extraordinaire) | "War does not determine who is right, C.S. System Group, Hebrew University, | but who is left" Jerusalem 91904, ISRAEL | [email protected] | -- Anonymous?
-----------[000124][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 1993 08:36:51 GMT From: [email protected] (Tony Li) To: comp.protocols.tcp-ip Subject: Re: BGP and Policy Routing
In article <[email protected]> [email protected] (Edward
S. Reynolds) writes:
Can I use BGP to allow 2 organizations to share a common IP backbone
with access to common resources yet prevent them from accessing each
other. The configuration might be something like this.
Networks A and B share a common backbone network C and have common
access to resources in network D. Network C is a transit network and
networks A, B and D are stub networks.
Can BGP prevent A and B from accessing each other by limiting route
advertisements in network C ?
BGP can prevent some route redistribution. A can reject routes leading
into B. C can also not advertise B's routes to A. And vice versa for
both.
Is this secure or merely an inconvenience for a network hack ?
That is, could someone in network B access network A via source-routing
or some other scheme ?
A _minor_ inconvenience. Any undergraduate worth their salt will, as you
note, source route around this, or tunnel through it. This is not a
security mechanism. You've just asked for an unlisted phone number. The
telemarketeers will still find you. ;-(
Can the
border routers prevent this since they have no knowledge of each other?
Given that the border routers are probably also packet filters, yes, the
border routers could probably implement most of what you want. However,
this is completely orthogonal to BGP.
I realize true and trusted security will require the use of Kerberos,
RSA or other authentification and encryption methods. The intent here
is to control the use of private network resources while providing a
common transport backbone.
Can BGP-3 handle this ?? BGP-4 ??
Yes, BGP-3 can handle the routing portion of this problem as long as each
site is one or more IP networks.
I suggest you contact your router vendor directly for more assistance. ;-)
Tony
-----------[000125][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Oct 1993 09:43:59 GMT From: [email protected] (Prashant N.Vaidya) To: comp.protocols.tcp-ip Subject: network mgmt s/w - tcpip & ipx - help !!!
Hi, We have a problem implementing a metwork management software on a company wide network. The background is this. We have a number of LANs at various locations in the country. The LANs are connected to each other over leased lines and using X.25 links. The LANs itself are very heterogenous. There are UNIX machines using TCPIP to communicate to each other. Then there are PCs connected by Novell's netware and using ipx/spx to communicate to each other. On such a network we want to develop a n/w mgmt s/w that recides on a dedicated unix machine. Among other functions it has also to sample data and carry out analysis of the network traffic. That's where the problem comes. Analysing captured packets is quite simple. It is merely having a series of filters. We haven't yet found a way to capture all the packets. From what we know about socket programming, we can only capture TCPIP packets from a socket. I don't have much experience with raw sockets. Knowledgeable netters can throw more light. Besides even with sockets, we can only capture TCPIP packets. And after that we have to bind a particular port. So we are actually listening only onto TCPIP packets at a particular port and not onto all the traffic on the ethernet. Thus, theoretically, while it i possible that we can "just turn on our machine and listen onto all the traffic on the network", practically we cannot achieve it. Additionally, there is the problem that we cannot capture ipx/spx packets at all. Does anybody know a solution? Thanks. This is for a friend og mine. You can post your answers to the net. svaidya.
-----------[000126][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Oct 1993 12:02:20 GMT From: [email protected] (Vic Mollett) To: comp.protocols.tcp-ip Subject: SYN in Time-wait state
I have recently noticed that one of my UN*X machines will sometimes do the
following (where XXXX is some constant):
SYN handshake with remote host from port XXXX
send data from port XXXX
FIN handshake with remote host from port XXXX
(note, we are in time-wait state here)
attempt SYN handshake with remote host from port XXXX with a sequence
number that is significantly greater than the one from the FIN
My question is, is this legal?? RFC 793 on page 69 seems to suggest that the
remote host should retransmit its last ack (from the FIN handshaking) and
toss the incoming packet. However, it seems intuitive that the host is wanting
to establish a new connection and is setting up a new sequence number (which is
what a SYN is supposed to do). Any ideas??
BTW, the two hosts do get synchronized (after a RST), but this little side-step
has me wondering.
--
/\ Vic Mollett
These opinions are my own and do not / \ Lexmark International, Inc.
necessarily reflect those of my employer. \ / [email protected]
\/
-----------[000127][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Oct 1993 13:21:16 GMT From: [email protected] (Joseph D. Courtney) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: FTP PC/TCP 2.2, Windows 3.1 and remote printing
([email protected]) wrote: : I have just recently installed the PC/TCP 2.2 software for DOS and : Windows on a 486 machine. Everything seems to work fine except : for remote printing. : : For several days I have been working on the problem, and have been : trying to get through to someone at FTP without much luck. : : Remote printing under DOS seems to work fine using 'lpr' command. : : But when trying to access remote printers via windows apps, it just : doesn't behave itself. : : I have gone through the setup procedure several times- under FTp Network : Icon, then to printers, I setup a host:printer, username=nobody, type=pcnfs : port=lpt2, then I connect, and everything seems to be OK. : I also cannot get printing to work using type=pcnfs, but it works fine when I use the LPR protocol. You must first setup the printer in Control panel. I assigned my printer to LPT2 and made the connection to \\host-name\printer-name. Then I used the FTP Network Icon to complete the setup. : When I print I get several different results- the main one being that I : get nothing, but I have another strange effect, The PC (Windows) will hang : for about 30 seconds, and the speaker emits a click noise about every : 5 seconds. : I have also noticed this clicking noise. It seems to happen when the network is not responding. -------------------------------------------------------------------------------- Joe Courtney | "Remember that no matter where you go... Control Data Systems, Inc. | there you are!" Email: [email protected] | Buckaroo Bonzai Compuserve: 71644,500 |
-----------[000128][next][prev][last][first]---------------------------------------------------- Date: Fri, 08 Oct 93 13:49:55 GMT From: [email protected] (Tom McGrath) To: comp.protocols.tcp-ip Subject: statd and lockd
I am looking for a public domain version of statd and lockd. Does anybody know of one and if so where is it?
-----------[000129][next][prev][last][first]---------------------------------------------------- Date: Fri, 08 Oct 93 13:53:17 GMT From: [email protected] (Tom McGrath) To: comp.protocols.tcp-ip Subject: statd and lockd
Is there a public domain version of lockd and statd? If so how can I get it?
-----------[000130][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 1993 22:15:26 -0400 From: [email protected] (Jordan Hayes) To: comp.protocols.tcp-ip Subject: Re: TCP versus UDP, many clients - / few servers
Jeff Martin <[email protected]> writes: UDP methods increase speed ... In what way? /jordan
-----------[000131][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 1993 15:43:10 GMT From: [email protected] (Casper H.S. Dik) To: comp.protocols.tcp-ip Subject: Re: Broadcast RPC
[email protected] (Amos Shapira) writes: >1. The client broadcasts on the net to the portmappers (UDP port 111) asking > on which port and which version is supported on the various hosts. (1 > packet). >2. The client receieves replies from all the portmappers telling it what port > to use in order to talk to your UDP server (n packets). >3. The client starts talking to each server individually, because almost all > of them sit on a different port broadcast isn't used here (another n > packets sent and another n packets recived). This is not right. Broad cast rpc works like this: - a broadcast call is send to port 111. this is an indirect call. - all portmappers in turn call the procedure specified indirectly. the daemons reply to the protmapper and in turn the portmapper replies to the client. Since broadcast is lossy, clnt_broadcast broadcast a number of times (3 times?). All the portmappers will reply to those requests again. clnt_broadcast will continue to do so until ``eachresult'' returns true or a timeout is reached. Best way to limit this broadcasting is keeping track of all servers that have responded. As soon as the duplicates are coming in, have eachresult return true. Casper
-----------[000132][next][prev][last][first]---------------------------------------------------- Date: 8 Oct 1993 15:48:19 GMT From: [email protected] (Xiao Feng QIAN) To: comp.protocols.tcp-ip Subject: FAQ
Hello, guys. I am a novice of this group. I think I 'd better to have a look at this group's FAQ first instead ask some s... questions. Could anyone tell me where I can find the faq about this group? Thanks a lot.
-----------[000133][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Oct 1993 16:34:49 GMT From: [email protected] (Art Berggreen) To: comp.protocols.tcp-ip Subject: Re: ICMP dropping options for IP
In article <[email protected]> [email protected] writes: >Hi, > >I have been trying to develop an alternate traceroute >program, but I am having trouble with the design. > >The design goes as follows: > Like traceroute, I send a packet to an unknown port on the > destination host. > Unlike traceroute, I have turned on the record route option in > the IP header. > > What I think SHOULD happen is the remote machine returns an ICMP > error message which should include the IP header of my > probe packet and therefore, the recorded route. Thus, I > would have a single probe version of traceroute. > > >Unfortunately, the IP header returned inside the ICMP message is marked >with a header length of only 20 bytes; the minumum for the IP header. >All my IP options and recorded route are missing. > >Does anyone know why ICMP does not include options in the IP header >that is returned? Sounds like a bug. The specs say that the received IP header plus at least the first 8 bytes of data above the IP header should be returned (to allow port numbers to be found). This would include any option fields in the received IP header. Art
-----------[000134][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Oct 1993 21:05:21 GMT From: [email protected] (Jeff Martin) To: comp.protocols.tcp-ip Subject: TCP versus UDP, many clients - / few servers
i am coding a network database and wish to optimize speed. we hope to use a many to few client/server model. that is many client processes 100-200 will be served by 5-20 database server processes on the network file server. UDP methods increase speed and simplify the many to few client/server model. however UDP lacks reliablity and increases complexity when the transaction size is > than MAX message size. TCP methods include reliability however they also seem to make the many to few client/server model impossible unless we create a new socket connection for each database transaction, which is way too costly. what protocol do network programmers use to optimize network speed? is their such a thing as a reliable datagram service? that is a reliable protocol that allows a client process to send a transaction to the server machine not neccessarily directed to a specific process, but instead a group of server processes all waiting to read from the same socket. adTHANKSvance, jeff -- Jeff Martin, dbms programmer, Philadelphia Phillies INET: [email protected] Voice: (814)234-8592x32 UUCP: attmail.com!astph!jeff FAX: (814)234-1269
-----------[000135][next][prev][last][first]---------------------------------------------------- Date: Fri, 8 Oct 1993 23:58:12 GMT From: [email protected] (Ben A. Mesander) To: comp.protocols.tcp-ip Subject: Re: OpenView Product Requirements
In article <[email protected]> [email protected] writes: [Large logo barphic deleted] We want to tell HP & HP OpenView Premier partners the types of requirements, comments/suggestion, Hot Issues, etc that will need to be addressed by the speakers at the conference. (We want the correct people present at the conference to answer the MAIL!!!) We want to make sure that speakers come prepared to address issues most important to YOU!! With that in mind, would you please: [...] Sure, but only if you promise to: - Omit large annoying logos from your articles. - Use only one (1) exclamation mark per sentence. --Ben
-----------[000136][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Oct 1993 00:11:48 GMT From: [email protected] (Ben A. Mesander) To: comp.protocols.tcp-ip Subject: Re: Broadcast RPC
In article <[email protected]> [email protected] (Amos Shapira) writes:
I think you loose here because the RPC servers are not all on the same
port. The scenario you have (if I get RPC right) is as follows:
1. The client broadcasts on the net to the portmappers (UDP port 111) asking
on which port and which version is supported on the various hosts. (1
packet).
2. The client receieves replies from all the portmappers telling it what port
to use in order to talk to your UDP server (n packets).
3. The client starts talking to each server individually, because almost all
of them sit on a different port broadcast isn't used here (another n
packets sent and another n packets recived).
No. What is happening is there are four separate broadcasts being made for
every one time you call clnt_broadcast(). It is most lame, and appears to be
an attempt to make UDP reliable. For this application, reliability is less
important than being lightweight. Four times all the remote portmaps look
up the remote port, contact the servers, and the servers respond.
Playing with etherfind, I can definitely show -four- identical broadcast
packets being sent every time I call clnt_broadcast()
--Ben
-----------[000137][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Oct 1993 01:39:14 GMT From: [email protected] (Line & Wade) To: comp.protocols.tcp-ip Subject: SLIP on VAX????
Does anyone have any recomendations for SLIP on a VAX 4000? I would really like to hear any share/freeware products that are out there and what is involved in installing them. Please forward responses to my email address. [email protected]
-----------[000138][next][prev][last][first]---------------------------------------------------- Date: Sat, 9 Oct 1993 06:11:52 GMT From: [email protected] (Scott Neugroschl) To: comp.protocols.tcp-ip Subject: Firewall -- how to set one up?
I will be setting up a firewall soon. I will have the following connections (addresses not yet received from our info systems dept)... Company Net _______ | | SCO | +----------+ ODT +--- lab ethernet | 2.0 | | server| ------- The ODT 2.0 server will have 2 ethernet cards and act as a gateway (and hopefully a firewall). Also do I have my terminology confused? What I really want is to allow access out of the lab net, but not into it. How do I go about setting this up? I apologize if this is not clear. Scott Neugroschl [email protected] -- Scott "The Pseudo-Hacker" Neugroschl -- Beat me, Whip me, make me code in Ada
-----------[000139][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 93 06:23:35 GMT From: [email protected] (Mark) To: comp.protocols.tcp-ip Subject: ICMP unreach bombing (nukes)
Hi all, I am interested in getting as much information about what can be done to reduce the effect of ICMP nukes sent by malicious cracker types. It's a fairly common occurence these days to get a nuke at least once a day from various places. Some sites have programs/machines setup to monitor and record them but as to what is done about them afterwards, thats a gray area. Some admins think that patching their machines would stop the problem for them, notably patch 100567-04 for Sun machines being an example. What happens at times is that the patches dont go all the way to protecting oneself from the nukes, as it's still possible to get hit. Wether it's impossible to stop or they just didnt do it right isnt something I can say with any certainty. Any advice in that area would be appreciated. If a site is identified as being a frequent source of such nukes is it prudent to ask the ip supplier for that site to restrict packets from the machine or subdomain? I dont think replying in kind is really the way to go so what can one do about it? Also would one of the net.gurus like to lay out exactly what happens when a nuke is sent, I basically know but I want to make sure I didnt miss anything. I have several sources for the nukers (DONT email asking for them) and have access on a limited basis to kernel code to study both so as much detail as possible would be good. Awaiting any and all replies. Email to me directly would be preferred. Thanks, Mark [email protected] [email protected]
-----------[000140][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 93 09:44:10 GMT From: [email protected] (Darren Reed) To: comp.protocols.tcp-ip Subject: Re: ICMP unreach bombing (nukes)
[email protected] (Mark) writes: [...] >Some admins think that patching their machines would stop the problem for >them, >notably patch 100567-04 for Sun machines being an example. What happens at >times is that the patches dont go all the way to protecting oneself from the >nukes, as it's still possible to get hit. Wether it's impossible to stop or >they just didnt do it right isnt something I can say with any certainty. >Any advice in that area would be appreciated. Use a Unix which uses the patched NET-2 network code or doesn't use the 4.3BSD networking code but its own properly constructed code. One example is NetBSD 0.9. It is based on NET-2 and the bug patched. It is possible to stop them all, but in doing so you are resigned to waiting for connect to timeout rather than report "host unreachable". The main problem with the 4.3 code is that an error received and processed for one TCP connection effects all connections that match the host IP pair, not just the one the error was received for. To fix the problem entirely was easier to change over the entire networking code which was done with Solaris2 I believe. [...] >Also would one of the net.gurus like to lay out exactly what happens when a >nuke is sent, I basically know but I want to make sure I didnt miss anything. >I have several sources for the nukers (DONT email asking for them) and have >access on a limited basis to kernel code to study both so as much detail as >possible would be good. Quite simple I think. ICMP error is received by one side, assuming it is a legit reply, does error processing which closes down the socket locally. Next packet sent along to the victim side is for a connection which no longer valid, kernel sends back a reset and the other side closes. Darren
-----------[000141][next][prev][last][first]---------------------------------------------------- Date: Sat, 09 Oct 93 10:30:08 GMT From: [email protected] (Damiano Bolla) To: comp.protocols.tcp-ip Subject: Any paper on variable length addressing ?
Can anybody point to one or more papers on performance issues and impact on routing of a variable length addressing scheme ? This can be either for CO or CL networks. Thanks ! Damiano
-----------[000142][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 1993 15:39:02 GMT From: [email protected] (Bernard Pottier) To: comp.protocols.tcp-ip Subject: Point to Point or SLIP between Sun and Mac & modem
Could somebody help to find a quick solution to carry TCP/IP over a modem link with SUn 4.1 on one side and Mac Sys7 on the other end? The goal is to run MacX using a 14.4 modem. Thanks. [email protected]
-----------[000143][next][prev][last][first]---------------------------------------------------- Date: 9 Oct 1993 17:14:56 GMT From: [email protected] (Shane Vincent Cantwell) To: comp.protocols.tcp-ip Subject: Wanted: DOS/Windows-based SLIP
Cheap or PD preferred - reply E-mail, please. [email protected] colorado.edu is my preferred address. Thanks.
-----------[000144][next][prev][last][first]---------------------------------------------------- Date: Sun, 10 Oct 1993 00:28:15 GMT From: [email protected] (Carlo Milono) To: comp.protocols.tcp-ip Subject: Re: Is there a 5 hub limit on UTP tcp/ip?
In article <[email protected]> [email protected] (James A Robinson) writes: >Sorry for what is probably a very newbie question, but if a network >has five hubs (four UTP hubs and a UTP/BNC repeater) will it mean that >the computers on hub one will not be able to talk to the computers on >hub five because the signal cannot go over five hub hops? The earliest implementations of 802.3 used repeaters to regenerate the signal to gain a distance advantage. These early products were such that the spec was written so that it appeared 'etched in stone' that four repeaters were the absolute limit. ...time passes. 10BASE-T emerges. Vistas open, etc. Actually, what you must concern yourself with is 'round-trip bit delay'. In a bus-oriented media, you must find the longest possible path (without a bridge or router), and calculate each hop (Computer-wire-hub-wire-hub-etc.) and each element has a value that can be applied to the bit delay. Your NIC must still be transmitting to sense a collision of its own transmission! You cannot launch a packet (take the smallest possible one) and forget about it! You must watch it and listen (round trip). Another factor: preamble erosion. If your hubs do not support preamble regeneration, you may have another limit to worry about. Each hub will waste a few bits of the preamble to get in sync, and then it will pass the packet along all routes...and through more hubs...until it is possible that you have no more preamble to sync up to. This is also sometimes called 'inter-packet gap shrinkage', but that is a slightly different story. -- +--------------------------------------------------------------------------+ | Carlo Milono: [email protected] | |"When a true genius appears in the world, you may know him by this sign, | |that the dunces are all in confederacy against him." - Jonathan Swift | +--------------------------------------------------------------------------+
-----------[000145][next][prev][last][first]---------------------------------------------------- Date: Sun, 10 Oct 1993 19:32:37 -0800 From: [email protected] (Jeff masud) To: comp.protocols.tcp-ip Subject: Re: Eudora for mac using slip
In article <[email protected]>, [email protected] (Brian Robert Perkins) wrote: > I'd like to get Eudora running on my friends mac via slip. I got Eudora, and > I got the slip connection running using the NCSA telnet with slip. I think I > need something else, but I don't know. I'm a PC man myself. Might there be a > mac (slip) tcpip faq somewhere? Yeah you can SLIP on the Mac, there is a program called MacSlip v1.0 and VersaTerm-PRO which also has SLIP software in their package if memory serves me right. They are both commercial programs, so he'll have to go out and buy'm. Jeff
-----------[000146][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 03:11:14 -0800 From: [email protected] (Wilson Cheung) To: comp.protocols.tcp-ip Subject: Re: Eudora for mac using slip
In article <[email protected]>, [email protected] (Jeff masud) wrote: > In article <[email protected]>, > [email protected] (Brian Robert Perkins) wrote: > > > I'd like to get Eudora running on my friends mac via slip. I got Eudora, > > and I got the slip connection running using the NCSA telnet with slip. I > > think I need something else, but I don't know. I'm a PC man myself. Might > > there be a mac (slip) tcpip faq somewhere? > > Yeah you can SLIP on the Mac, there is a program called MacSlip v1.0 and > VersaTerm-PRO which also has SLIP software in their package if memory > serves me right. They are both commercial programs, so he'll have to go > out and buy'm. Besides the commercial packages MacSLIP and VersaTerm SLIP, there's one more SLIP client packet driver available for the Mac...InterSLIP, and it's FREE! InterSLIP 1.0.1 is available via anonymous FTP from: ftp.intercon.com:/InterCon/sales/InterSLIP1.0.1.image.hqx -- Wilson Cheung [email protected]
-----------[000147][next][prev][last][first]---------------------------------------------------- Date: Sun, 10 Oct 93 22:33:00 -0500 From: [email protected] (Tom Kauffman) To: comp.protocols.tcp-ip Subject: Internic Mail Daemon Address
Help! I got this lovely memo from the Internic reference desk last week on using the mail daemon to request RFCs -- but it doesn't include the mail daemon address. I've tried ds.internic.net and [email protected] (from what I remember of the conversation with the reference desk) and both bounced.
-----------[000148][next][prev][last][first]---------------------------------------------------- Date: Sun, 10 Oct 1993 21:52:43 GMT From: [email protected] (Joe Kellett) To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: Re: IP over VSAT network
Mark Reardon ([email protected]) wrote: : The RS/6000 at one of our customer sites is running FTP (TCP/IP based) : and the ping times are in the 1 to 2 second range. That is from a : VSAT to the Customers data center (one satellite hop). If your destination : is on another VSAT then the double hop and switch decision would probably : double that. So, the low end of your range seems reasonable and the high : could be caused by congestion and queueing. <deletions> : As long as the delay doesn't double, no time out will occur. If it does, : a retransmission will occur. My experience is that the RS/6000 worked : well in our environment. How well does telnet work with this kind of delay (your low-end delay)? I understand characters echo back from the far end when using telnet, which (I speculate in total ignorance) would cause an annoying "type-behind" effect. I suppose ftp could be tuned for this kind of environment with larger window sizes? I have experience with SNA over GTE Spacenet (using poll spoofing), and they're also talking about having a "router" function "soon". Thanks. -- Joe Kellett [email protected]
-----------[000149][next][prev][last][first]---------------------------------------------------- Date: Sun, 10 Oct 1993 23:46:53 GMT From: [email protected] (Brian Robert Perkins) To: comp.protocols.tcp-ip Subject: Eudora for mac using slip
I'd like to get Eudora running on my friends mac via slip. I got Eudora, and
I got the slip connection running using the NCSA telnet with slip. I think I
need something else, but I don't know. I'm a PC man myself. Might there be a
mac (slip) tcpip faq somewhere?
Happily using slip on PC, but expanding my horizons
Brian R Perkins
[email protected] or
[email protected]
-----------[000150][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 00:53:36 GMT From: [email protected] (Roy - Kim) To: comp.protocols.tcp-ip Subject: rfc(s) on ports and port configurations?
I am trying my darndest to find the rfc's that document port and port configuations on machines. i.e. telnet uses port info along with the i.p. address. Any info on this would be greatly appreciated. Please either post or e-mail responses. Thanks, -Roy -- =============================================================== Roy Kim ([email protected]) "The future is here for those who have the vision to grab it." Disclaimer: 1 + 1 = 3 This is an Alchemic solution.
-----------[000151][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 01:28:49 GMT From: [email protected] (David P. Maynard) To: comp.protocols.tcp-ip Subject: dynamic address BOOTP server
I am trying to set up a SLIP server running on a BSD/386 box. Users will dial in on a rotary and will receive a "random" (port-based) IP address each time they login. I would like it to behave similarly to a CISCO box so that I can adapt client-side software written for that environment. My biggest problem right now is getting a BOOTP server that knows how to deal with this. The BOOTP requests from the SLIP clients have null IP addresses and either zeroed or nonsense hardware addresses. Since the request itself is meaningless, the BOOTP server needs to craft a response based on the SLIP interface on which a request arrives. Unfortunately, with datagram sockets, there seems to be little tracking information available. I've been looking at the NetBSD source (assuming it's pretty close to the BSDI code), and haven't quite figured out how to discover the originating interface for a datagram. Does the IP address of the SLIP interface get stored anywhere when the message comes in? It looks like some of the source routing code might be useful, but it appears to be partially ifdef'ed out. Any suggestions? I'll keep experimenting to see if I come up with an answer, but I would appreciate any hints. Thanks, David -- David P. Maynard, Carnegie Mellon University & Dependable Solutions USMail: 14312 Richard Walker Blvd, Austin, TX 78728-6862 EMail: [email protected], Tel: +1 512 251 8122, Fax: +1 512 251 8308 --
-----------[000152][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 03:21:34 GMT From: [email protected] (Steve Alexander) To: comp.protocols.tcp-ip Subject: Re: timed vs. NTP (was: Specifying IP)
In article <[email protected]> [email protected] (Vernon Schryver) writes:
>>Actually.... did you change timed so that "date <new-time> ; rdate" works
>>on systems other than the master? That's only a partial fix, but it's far
>>better than not having it at all.
>
>Which `rdate` did you use? What did it do?
The rdate in question merely notifies the time daemon using the same TSP PDU
used by the 4.3BSD date command. It exists as a separate command only because
it was not feasible for us to change the OS date command. It is unfortunately
mis-named which causes confusion with the rdate command found in other systems
(e.g. SunOS).
For purposes of this discussion, treat "date;rdate" on a SCO system as
equivalent to "date" on a 4.3BSD system.
I don't recall that the PDU in question needs to be sent to the "master"; I
believe it is sent to the local timed, which in turn notifies the "master."
(if the local daemon is not the "master"). That is what the TSP document says,
although it could be wrong, I suppose. Better go check the code...
Vernon, is there a summary of the differences between the 4.3-Tahoe and 4.4
versions of timed? (yeah, yeah, I'll look at the code... :-)
--
Steve Alexander, Lachman Technology, Inc. | [email protected]
(708) 505-9555 x256 FAX: (708) 505-9574 | ...!{sun,ico}!laidbak!stevea
-----------[000153][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 05:07:38 GMT From: [email protected] (Matthew Lyle) To: comp.protocols.tcp-ip Subject: Re: Eudora for mac using slip
[email protected] (Jeff masud) writes:
>In article <[email protected]>,
>[email protected] (Brian Robert Perkins) wrote:
>>I'd like to get Eudora running on my friends mac via slip. I got Eudora, and
>>I got the slip connection running using the NCSA telnet with slip. I think I
>>need something else, but I don't know. I'm a PC man myself. Might there be a
>>mac (slip) tcpip faq somewhere?
>Yeah you can SLIP on the Mac, there is a program called MacSlip v1.0 and
>VersaTerm-PRO which also has SLIP software in their package if memory
>serves me right. They are both commercial programs, so he'll have to go
>out and buy'm.
MacSlip is now up to version 2.0. FYI.
--
Matthew Lyle [email protected]
[email protected]
OpenConnect System, Dallas, Texas (214) 888-0474
-----------[000154][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 11:35:31 From: [email protected][128.127.125.119] (Larry Backman) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: FTP PC/TCP 2.2, Windows 3.1 and remote printing
In article <[email protected]> [email protected] (Joseph D. Courtney) writes: >> : When I print I get several different results- the main one being that I >> : get nothing, but I have another strange effect, The PC (Windows) will hang >> : for about 30 seconds, and the speaker emits a click noise about every >> : 5 seconds. >> : >> I have also noticed this clicking noise. It seems to happen when the >> network is not responding. >> The click indicates that the NFS redirector is retranmitting a request. That's probably why your NFS printing is failing. You ought to send our support dept ([email protected]) a trace of the network traffic when the click occurs. Larry Backman FTP Software
-----------[000155][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 93 07:04:03 GMT From: [email protected] (Shane Catton) To: comp.protocols.tcp-ip Subject: winqvtnet and bootpd
We have netware lan with PCs. We are trying to get winqvtnet working with bootp server on our netware server. is any one using winqvtnet and bootp. I'm sure the bootp server is OK as NCSSA telnet works fine. Its just winqvtnet comes back with error BOOTP failure. we have netware 3.11 server we have version 3.3 winqvtnet we have BOOTP.NLM from Hellsoft software. any help greatly appreciated. shane catton email: [email protected]
-----------[000156][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 09:06:38 GMT From: [email protected] (Mark Whidby) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: PC-NFS 5.0 over packet driver ?
In article <[email protected]>, [email protected] (Jan-Piet Mens) writes: |> I would like to run PC-NFS 5.0 over a packet driver. I believe I |> need a new \NFS\PCNFS.SYS for this. Can someone enlighten me ? |> Where can I get the PCNFS.SYS file for packet driver (archie doesn't |> say much... :-) You need a driver called PKTD.SYS (no new PCNFS.SYS); you can get it from ftp.york.ac.uk and other places -- _____________________________________________________________ Mark Whidby, Distributed Systems, Manchester Computing Centre
-----------[000157][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 11:32:37 GMT From: [email protected] (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Re: Diferences using RPC with UDP and TCP?
see paper in IEEE Networks by wakeman et al jauary 1992 - covers RPC over tcp, (though its about a performance problem). -- jon crowcroft (hmmm...)
-----------[000158][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 1993 11:55:49 GMT From: [email protected] (Peter Langstoeger) To: comp.protocols.tcp-ip,vmsnet.networks.tcp-ip Subject: Unknown IP address
Hi. Can anybody tell me, what the IP address [224.0.0.2] is ? It is not a class A, B or C address. I found a new workstation in my network, which generates messages to this IP address and uses 010065000002 as target DLC (multicast) address, which is again unknown to me. (SNIFFER says IANA, but what is it ?) TIA -Peter -------------------------------------------------------------------------------- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2382 Network and VMS system manager Fax. +43 1 81111-888 Technical Computer Center (ADV) E-mail [email protected] KAPSCH AG Wagenseilgasse 1 PSImail PSI%(0232)281001141::Peter.Langstoeger A-1121 VIENNA AUSTRIA "I'm not a pessimist, I am a realist"
-----------[000159][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 12:23:32 GMT From: [email protected] (Mark Reardon) To: comp.protocols.ibm,comp.protocols.tcp-ip Subject: Re: IP over VSAT network
In article <[email protected]>, [email protected] (Joe Kellett) writes: |> Mark Reardon ([email protected]) wrote: |> |> How well does telnet work with this kind of delay (your low-end delay)? I |> understand characters echo back from the far end when using telnet, which (I |> speculate in total ignorance) would cause an annoying "type-behind" effect. |> I suppose ftp could be tuned for this kind of environment with larger window |> sizes? I have experience with SNA over GTE Spacenet (using poll spoofing), |> and they're also talking about having a "router" function "soon". |> |> Thanks. |> -- |> Joe Kellett |> [email protected] Telnet usually supports a local echo option (mode line) that allows the characters to be echoed locally. Then the delay is at the end of command lines. The responses to commands are slower but you are after all using a satellite link. Also, be aware of applications that echo characters other than those typed. They must be run in mode character. -- _____________________________________________ Mark Reardon AT&T Tridom (404-514-3383) email: [email protected], attmail!tridom!mwr
-----------[000160][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 12:48:52 GMT From: [email protected] (John Hascall) To: comp.protocols.tcp-ip Subject: Re: Unknown IP address
[email protected] writes:
}Can anybody tell me, what the IP address [224.0.0.2] is ?
}It is not a class A, B or C address.
}I found a new workstation in my network, which generates messages to this IP
}address and uses 010065000002 as target DLC (multicast) address, which is
}again unknown to me. (SNIFFER says IANA, but what is it ?)
% whois 224.0.0.0
University of Southern California (NET-MCAST-NET)
Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, CA 90292-6695
Netname: MCAST-NET
Netnumber: 224.0.0.0
:
:
Indeed, it appears to be an IP multicast.
John
--
John Hascall ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
-----------[000161][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 13:53:37 GMT From: [email protected] (Leigh Dodd) To: comp.protocols.tcp-ip Subject: NE2000 Software Tester
Hi All
Does any one know of a GOOD bit of software that will test the NE2000
card and give me some info back?.
I'm having problems getting one to work with NDIS or ODI drivers and
on various machines. The NDIS driver reports back with "ADAPTER RAM TEST FAIL"
but I've tried every Address and Interrupt combination. The fault is a
conflict with another board but I need a bit more info on the card. BTW. It's
not the NE2000 card, I have another 10 and they are the same.
Thanks
Leigh
--
*******************************************************************************
* Leigh Dodd (Sun System Administrator) | Three Steps to Heaven *
* University of Sussex | 1). C.B.T. ----- Passed *
* Brighton, England. | 2). Part 2 ----- Passed *
* INTERNET: [email protected] | 3). Gota GPz550 and Riding To HELL *
*******************************************************************************
-----------[000162][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 93 21:17:01 MDT From: [email protected] (869883 Desai Rutvij Chandrahas) To: comp.protocols.tcp-ip Subject: ERROR IN gethostbyaddr() call
hi,
I have some problem in gethostbyaddr() system call. It is returning
NULL.
The segment of my code is like this:
sockfd2 = accept(sockfd1,(struct sockaddr *) &cli_addrp,&addrlen);
hp = gethostbyaddr((char *)&cli_addrp->sin_addr,sizeof(structin_addr),
cli_addrp->sin_family);
if (hp)
hostname = hp->h_name;
else
hostname = inet_ntoa(cli_addrp->sin_addr);
my program is going into the else part because hp is NULL.
I don't know why?
Please send any suggesion.
Thanks
rutvij
-----------[000163][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 15:23:56 GMT From: [email protected] (Art Berggreen) To: comp.protocols.tcp-ip Subject: Re: Unknown IP address
In article <[email protected]> [email protected] writes: >Hi. > >Can anybody tell me, what the IP address [224.0.0.2] is ? >It is not a class A, B or C address. > >I found a new workstation in my network, which generates messages to this IP >address and uses 010065000002 as target DLC (multicast) address, which is >again unknown to me. (SNIFFER says IANA, but what is it ?) 224.0.0.2 is the All Routers IP multicast address. If the packet happened to be an ICMP packet, I'd guess that it might be a Router Discovery Query. Is this a fairly new release of TCP/IP software? Art
-----------[000164][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 17:14:40 GMT From: [email protected] (Louis Todd Heberlein) To: comp.protocols.tcp-ip Subject: IP level socket options
Aaauugggghhhhh! I have been trying to set an IP option on a raw socket for several days, but my setsockopt keeps failing. I have tries a number of combinations, but no luck yet. The error code returned is not of much use since according the man page IP(4P) the error that I am receiving (22 or EINVAL) can mean: An unknown socket option was given The IP option field was improperly formed; an option field was shorter than the minumum value, an option field was longer than the option buffer provided Could someone send me, or point me to, some sample source code where an IP options are set? Any help would be greatly appreciated. Thanks, Todd Heberlein [email protected]
-----------[000165][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 93 18:24:53 GMT From: [email protected] (Ashvini Nangia) To: comp.client-server,comp.protocols.tcp-ip,comp.os.misc,comp.unix.sys5.r3,comp.unix.sys5.misc Subject: Where can I get NTP for SVR4 ?
Where can I find a port of NTP (Network Time Protocol) for SVR4 based systems. If anybody out there is working on such a port or knows where to get one please let me know. Thanks in advance. - Ash Nangia [email protected] 512-244-8045
-----------[000166][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 18:34:36 GMT From: [email protected] (Ian Leveson) To: comp.protocols.tcp-ip Subject: Can FTP's PC/TCP coexist with MS Win. for WG?
I've just tried installing Microsoft's Windows for Workgroups on a PC which already has access to a unix server via FTP PC/TCP's NFS utilities. Has anyone managed to retain access to the TCP/IP network at the same time as connecting the PC to others via Windows for Workgroups? If so, how? I suspect that an appropriate network.inf and oemsetup.inf file would help do the trick: are such files available? Thanks in advance. Ian Leveson -- Ian Leveson internet: [email protected] Berlin Zerberus: [email protected] Germany Fax.: +49 (030) 853 10 82
-----------[000167][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 93 18:35:17 GMT From: [email protected] (Matt Brin) To: comp.protocols.tcp-ip Subject: more than one interface on one net
We would like to split our local net into two parts. Can we do this by putting a SUN with two ether interfaces in between the two parts? Both interfaces will have different IP addresses, but will be on the same net. We would run arpserv to have machines trying to reach "across" this machine use the etheraddress of this machine for their destinations. Will the "bridge" machine know how to forward properly? _____________________________________________________________________________ matt brin / math. dept / SUNY / Binghamton, NY 13902-6000 / (607)-777-2147 [email protected] INTERNET [email protected] BITNET -----------------------------------------------------------------------------
-----------[000168][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 93 00:18:49 From: [email protected] (Allan Leinwand) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Re: Is RMON a standard yet?
> Can anyone out there tell me if RMON has become a standard yet? If
> it is not a full standard, what are the groups that have been stand-
> arized?
Hello Gerard,
To the best of my knowledge, the RMON MIB is standardized in RFC
1271.
Thanks,
Allan Leinwand
cisco Systems
(510) 831-4730
[email protected]
-----------[000169][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 1993 20:46:30 GMT From: [email protected] (Tom Walsh) To: comp.protocols.tcp-ip Subject: Re: Design of parallel TCP. Is it possible
I have an IP which is able to be symetrified, my TCP/UDP is based off the same model but it would be best to keep each connection locked to a local single processor, and it ( TCP ) has not been tested for true parallelism. The model does allow ~line speed ethernet TCP. --- ----------*----------*----------*---------*---------*---------* Tom Walsh "To Internet or not to Internet, That is the question" ( 408 ) 749-1600 ext 153 ( 408 ) 749-1690 ( FAX ) internet: [email protected] ---------*----------*----------*---------*---------*---------*
-----------[000170][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 1993 21:09:00 GMT From: [email protected] (Valdis Kletnieks) To: comp.protocols.tcp-ip Subject: Re: Unknown IP address
In article <[email protected]> [email protected] writes: >Can anybody tell me, what the IP address [224.0.0.2] is ? >It is not a class A, B or C address. Congradulations. You've found a "multicast" address group. Most likely, it's a newer Sun or DEC (maybe HP) workstation that has the kernel support for IP multicast (which has been around for ages but nobody supported correctly). Valdis Kletnieks Computer Systems Engineer Virginia Tech
-----------[000171][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 21:33:47 GMT From: [email protected] (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: timed vs. NTP (was: Specifying IP)
In article <[email protected]> [email protected] (Steve Alexander) writes:
>...
>The rdate in question merely notifies the time daemon using the same TSP PDU
>used by the 4.3BSD date command. It exists as a separate command only because
>it was not feasible for us to change the OS date command. It is unfortunately
>mis-named which causes confusion with the rdate command found in other systems
>(e.g. SunOS).
>
>For purposes of this discussion, treat "date;rdate" on a SCO system as
>equivalent to "date" on a 4.3BSD system.
Ugh. I would never have guessed that `rdate` does that. Why not simply
change the date command? Why not chose a better name than rdate? How do
you avoid races with `timed` changing things between the `date` and the
`rdate` in `date;rdate`? That's why the 4.3BSD `date` relies on timed to
do the change. Oh, well. I know of and have particpated in the
"non-technical issues" that cause such foulups.
>I don't recall that the PDU in question needs to be sent to the "master"; I
>believe it is sent to the local timed, which in turn notifies the "master."
>(if the local daemon is not the "master"). That is what the TSP document says,
>although it could be wrong, I suppose. Better go check the code...
Yes, of course, you're right.
>Vernon, is there a summary of the differences between the 4.3-Tahoe and 4.4
>versions of timed? (yeah, yeah, I'll look at the code... :-)
The code is the only useful summary of differences. It's hard to remember
the whats of years of hacking, let alone the whys you seem to have done
whatever you did. There was a "changes" file on vangogh. Enclosed below
is most it.
Vernon Schryver [email protected]
-----
improve `timedc msite` to accept a list of hostnames.
change slave-masters to answer the packets generated by `timedc msite`
with the name of the real master, not their own. This makes it
possible to "chase the chain" of slave servers to the ultimate
master.
much improve the log caused by `timedc trace on`:
-made `timed -t` work.
-suppression of repeated entries, which both slowed down the daemon
(sometimes catastrophically) and tended to make disks fill up
even more quickly.
-better time stamps on log entries
-more messages
-dump information about slaves, master, and so on each time
a message asking the log be turned on is received, and
when the log is turned off.
-fewer CPU cycles
use a hash table to keep track of slaves, instead of the stupid linear
list. This becomes handy with hundreds of slaves, instead of
the original design limit of "a room with a few VAX's."
separate the main protocol timer from that used to look for other networks
to master.
time stamp packets received by the daemon, so that time corrections
are not made (even more) inaccurate by waiting in the internal,
timed queue while the daemon is processing other messages.
made -n and -i work with subnets not named in /etc/networks
compute the median of the measured clocks, instead of the average
of "good" times.
vastly improve the accuracy of the clock difference measure by
`timedc clockdiff`.
use adjtime() when possible, and directly set the clock only when
necessary.
when the requested adjustment is small, perform only part of it, to
damp oscillations and improve the long term accuracy of the
adjustments.
fix uncounted core-dumps on machines that do not allow dereferencing 0
in both the daemon and timedc.
fix "master loop detection".
fix several cases in which multi-homed masters could get into shouting
matches, consuming all available network bandwidth and CPU cycles
(which ever runs out first), and convincing all bystanders to stop
advancing their own clocks.
refuse to behave badly when other machines do. Instead of arguing forever,
go off and sulk when other machines refuse to play by the rules.
increase the maximum number of clients.
add "-F host,host2,..." to "freerun" or "trust" only some hosts. This
is handy both when only some machines should be trusted to let
root use the `date` command to change time in the network.
It is also handy when one machine has some other way of adjusting
its clock, whether NTP or a direct radio or atomic connection.
"-F localhost" causes `timed` to "trust" only itself.
It is also handy to build a hierarchy of timed masters crossing
networks. The TSP protocol has no provision of "goodness of clock",
no natural way to completely heal network paritions. Judicious
use of -F or -G can cause each gateway to trust only itself and
machines closer to a central machine with a radio or atomic clock.
add #ifdef code that supports NIS "netgroups" of trusted hosts, which
can be easier to administer than -F.
add #ifdef code to compute an aged total adjustment. This can be used
in systems that can make long term changes in their system clock
frequency, e.g. "timetrim" in the Silicon Graphics kernel.
Problems observed by others that are unresolved include:
Practically any users can send to the master TSP messages and this
way corrupt the reliability of the system. Authentication
of messages should be provided. Unfortunately, that would
require changing the protocol with all of the implied
compatiblity problems. Fortunately, the new -F and -G args
can be used to cause the daemon to ignore time changes from
untrusted machines.
MAN. The limit of 1013 on the number of slaves hosts should be doc'ed.
It should be dynamically allocated with no limit. On a
large network, one host could possibly master over many
more than 30 hosts. Given the timers in the code and
effectively in the protocol, and the time required by each
master to talk to each slave, it is not practical to have
more than 200-300 slaves. The master cannot keep up because
the slave-chatting is single-threaded. when the master
gets behind, slaves start demanding elections. To
significantly increase the number of slaves would require
multi-treading things, and given that a network with more
than 300 directly addressable machines has worse problems
than keep the time of day right, not worth worrying about.
-----------[000172][next][prev][last][first]---------------------------------------------------- Date: Mon, 11 Oct 1993 23:27:09 GMT From: [email protected] (CJS Vance) To: comp.protocols.tcp-ip Subject: Re: Unknown IP address
In article <[email protected]> [email protected] writes: | Can anybody tell me, what the IP address [224.0.0.2] is ? | It is not a class A, B or C address. | | I found a new workstation in my network, which generates messages to this IP | address and uses 010065000002 as target DLC (multicast) address, which is | again unknown to me. (SNIFFER says IANA, but what is it ?) It's a class D address. Dig says ; <<>> DiG 2.0 <<>> -x ;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6 ;; flags: qr aa rd ra ; Ques: 1, Ans: 1, Auth: 0, Addit: 0 ;; QUESTIONS: ;; 2.0.0.224.in-addr.arpa, type = ANY, class = IN ;; ANSWERS: 2.0.0.224.in-addr.arpa. 86400 PTR ALL-ROUTERS.MCAST.NET.
-----------[000173][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 00:27:28 GMT From: [email protected] (Anthony Rumble) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp.ip,comp.protocols.ppp,comp.protocols.pcnet,apana.general Subject: Looking for alternative to pc-route...
Does anyone know of an alternative/replacement for pc-route. Be it Free, GNU, Shareware or Commercial.. Basic requirments.. Has to run on a PC based machine. Has to have SLIP and either CSLIP or PPP. Has to be able to handle RIP and Western Digital Ethernet cards. Thankyou in advance.. -- [email protected] APANA Sydney UUCP regional hub (feeds available) Anthony Rumble Linux Support OZ (02) 418-8750 v.32bis - 3 lines Voice (02) 418-8220 For information on APANA mail [email protected]
-----------[000174][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 00:46:13 GMT From: [email protected] (Anthony Rumble) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp.ip,comp.protocols.ppp,comp.protocols.pcnet,apana.general Subject: Re: Looking for alternative to pc-route...
Anthony Rumble ([email protected]) wrote: : Does anyone know of an alternative/replacement for pc-route. : Be it Free, GNU, Shareware or Commercial.. : Basic requirments.. : Has to run on a PC based machine. : Has to have SLIP and either CSLIP or PPP. : Has to be able to handle RIP and Western Digital Ethernet cards. Oh.. P.S.. Don't suggest KA9Q.. It's too slow. -- [email protected] APANA Sydney UUCP regional hub (feeds available) Anthony Rumble Linux Support OZ (02) 418-8750 v.32bis - 3 lines Voice (02) 418-8220 For information on APANA mail [email protected]
-----------[000175][next][prev][last][first]---------------------------------------------------- Date: 11 Oct 1993 23:06:17 +0100 From: [email protected] (Matthias Urlichs) To: comp.protocols.tcp-ip Subject: Re: problems with large packets on UDP
In comp.protocols.tcp-ip, article <[email protected]>,
[email protected] writes:
>
> So I would like to know if it is a well known problem of IP segmentation,
>or if I have forgotten an operation whose missing makes the sending of
>messages longer than 30400 bytes impossible. For the moment I do not
>understand what happens, and why the sending of packets whose size is around
>40000 bytes is impossible while UDP sockets allow it.
>
[ Please keep your lines to <80 characters ]
Looks like a signed 16-bit integer to me... i.e., a kernel bug.
If I were you, I wouldn't send one large UDP packet and let the IP layer
split it -- split it yourself, say to 8k or so (same as NFS...). That way you
receive bits and pieces of your picture, enabling you to keep old picture
fragments around in case a packet gets lost. If that happens to your big UDP
packet, the whole picture gets tossed when the kernel times out (which can be
a few seconds).
--
Adam was but human -- this explains it all. He did not want the apple for
the apple's sake, he wanted it only because it was forbidden.
-- Mark Twain, "The Tragedy of Pudd'nhead Wilson"
--
Matthias Urlichs \ XLink-POP Nürnberg | EMail: [email protected]
Schleiermacherstraße 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 Nürnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
-----------[000176][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1993 08:25:48 -0400 From: [email protected] (Ted Morris) To: comp.protocols.tcp-ip,comp.protocols.ppp Subject: IPX via SLIP/PPP?
Our University is instituting SLIP access through Zyplex multiprotocol terminal servers. A project I'm working on is going to install the "same" equipment so they can be managed together. PPP is not planned immediately but is an option with this server. Supposedly, it ought to be possible to "tunnel" IPX packets through IP; I think I've also heard that upcoming Novell releases will allow the use of TCP or IPX to move the Novell information (?)... Has anyone -successfully- put a pc running IPX/NETx in touch with a remote Novell server through a SLIP or PPP connection to the Novell's LAN? I recognize that 1) the Novell server must be running TCP/IP in some flavor (LAN Workplace?), 2) the pc must be running both TCP/IP and IPX (LAN Workplace again?) (at present), and 3) the pc must be running a SLIP or PPP package and communicating with a suitable SLIP/PPP server on the same internetwork as the Novell server. From what we've read, we think this -could- be do-able, but haven't heard of any successful installations yet. We want to make our remotely connected pcs both nodes on the TCP/IP network and clients of the Novell server, basically, so they can run some of the Novell-stored MS-DOS/etc. software. (Yes, we know that will be slow...) Thanks for any comments/suggestions/pointers. Theodore Allan (Ted) Morris, University of Cincinnati Medical Center, 513-558-0177V, -2682F, MOR[email protected], [email protected], WB8VNV Previous politically-incorrect tag-line removed.
-----------[000177][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1993 08:02:49 GMT From: [email protected] (Tony Li) To: comp.protocols.tcp-ip Subject: Re: problems with large packets on UDP
In article <[email protected]> [email protected] (Matthias
Urlichs) writes:
If I were you, I wouldn't send one large UDP packet and let the IP
layer split it -- split it yourself, say to 8k or so (same as NFS...).
That way you receive bits and pieces of your picture, enabling you to
keep old picture fragments around in case a packet gets lost. If that
happens to your big UDP packet, the whole picture gets tossed when the
kernel times out (which can be a few seconds).
In fact, if you can fragment your data yourself, it's much better to send
path MTU sized datagrams. NFS is not a particularly good model, as those
8k packets do get fragmented. Any loss of a single fragment implies
retransmission of all fragments for that packet.
Tony
-----------[000178][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 08:12:12 GMT From: [email protected] (Jon Crowcroft) To: comp.protocols.tcp-ip Subject: Re: Unknown IP address
In article <[email protected]>, [email protected] (Valdis Kletnieks) writes: |> In article <[email protected]> [email protected] writes: |> >Can anybody tell me, what the IP address [224.0.0.2] is ? |> >It is not a class A, B or C address. |> |> Congradulations. You've found a "multicast" address group. |> Most likely, it's a newer Sun or DEC (maybe HP) workstation that has the |> kernel support for IP multicast (which has been around for |> ages but nobody supported correctly). most likely its an SGI, which has had multicast support for quite a while:-) or a proteon router... -- jon crowcroft (hmmm...)
-----------[000179][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 13:10:48 GMT From: [email protected] (Ran Atkinson) To: comp.protocols.tcp-ip Subject: Re: Unknown IP address
In article <[email protected]> [email protected] (Valdis Kletnieks) writes: > Congratulations. You've found a "multicast" address group. Most > likely, it's a newer Sun or DEC (maybe HP) workstation that has the > kernel support for IP multicast (which has been around for ages but > nobody supported correctly). Regrettably, we can be quite certain that it isn't an HP workstation. HP is, per usual, behind in their TCP/IP and UNIX products and does not support IP multicasting at all. There are rumours that IP Multicast will be added when HPUX 10.x is released in a few years, but HPUX 9.x doesn't support it. It is probably an _SGI_ or a newer Sun or DEC machine. SGI was the first to ship IP multicast support, though Sun was not long behind (Solaris 2.x). DEC apparently supports IP multicast in their OSF/1 release only. SGI deserves some credit for being the most diligent vendor with regard to their TCP/IP networking feature set, correctness of implementation, and also performance. Ran [email protected]
-----------[000180][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 13:13:20 GMT From: [email protected] (Ran Atkinson) To: comp.client-server,comp.protocols.tcp-ip,comp.os.misc,comp.unix.sys5.r3,comp.unix.sys5.misc Subject: Re: Where can I get NTP for SVR4 ?
In article <[email protected]>, [email protected] (Ashvini Nangia) writes: >Where can I find a port of NTP (Network Time Protocol) for SVR4 systems. Despite wide crossposting, you didn't ask in the right place. The place to ask is in comp.protocols.time.ntp and I think the answer is that xntp3 does support many SVR4 implementations. Followups have been suitably redirected. This answer was posted rather than emailed in hopes of helping other folks find the right newsgroup for NTP material.
-----------[000181][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1993 13:54:20 GMT From: [email protected] (Venkatesh Nakkala) To: comp.databases.oracle,comp.protocols.tcp-ip Subject: HELP !!! ..Socket call in FORMS 3.0 User Exits giving an error....
Howdy,
I am trying to open connection to 2 TCP/IP servers from a user_exit
in the PRE_FORM Trigger... after making the runform30 executable and
running the form I get an error.......
Too many open files.........this is on the socket system call in the
user_exit...
Thanks in advance for any help,
Venkatesh Nakkala
[email protected]
--
Venkatesh Nakkala [email protected]
Off : (409)845-5481 Res : (409)846-7638
Dept. Of Comp Sci.,Texas A & M Univ. Fax : (409)847-8578
-----------------------------------------------------------------------------
-----------[000182][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 14:15:37 +0000 From: [email protected] (Phil Royse) To: comp.protocols.tcp-ip Subject: TCP/IP/OSI Convergence - from EWOS
To all those interested in TCP/IP and OSI Transport & Network layer
protocols, here is a message/invitaion from EWOS (European Workshop on OPen
Systems):
TCP/IP/OSI Convergence - Information from EWOS
-----------------------------------------------
Discussions are currently underway in EWOS (the European Workshop for
Open Systems) on the potential convergence of TCP/IP and OSI. Parties
both within and outside EWOS are being invited to submit contributions
to these discussions, and particularly to an initial EWOS meeting on
the subject of TCP/IP/OSI convergence to be held October 25th 1993.
Information and contributions concerning TCP/IP/OSI convergence are
being made available on the EWOS Information Server.
This document provides details of how to access TCP/IP/OSI directory
on the EWOS Information Server and where to send comments and
contributions.
Submission of Comments and Documents on TCP/IP/OSI Convergence
---------------------------------------------------------------
Please send contributions to:
EWOS Secretariat
Rue de Stassart 36
B-1050 Brussels
Belgium
Telephone: +32 2 511 7455
Fax: +32 2 511 8723
X.400: c=be; a=rtt; p=y-net; o=sp1; s=ewos
rfc mail: [email protected]
OR
Chris Makemson
EWOS TCP/IP/OSI Convergence Coordinator
CMC Ltd
22 Bourne Firs
Lower Bourne
Farnham GU10 3QD
United Kingdom
X.400: c=gb; a=gold 400; p=level-7 ltd; o=cmc ltd; s=makemson; g=chris
rfc-822: [email protected]
Telephone: +44 252 783 8855
Fax: +44 252 783 8855
Accessing the TCP/IP/OSI Directory on the EWOS Information Server
-----------------------------------------------------------------
This directory is called tcp-ip-osi and is located in the top level
menu.
The server can be accessed interactively or via Email.
Interactive Addresses
X.25: EuropaNET network: 2043 3450 3999 66
Public X.25: 2342 3440 0193 66
Telnet: concise.level-7.co.uk
146.97.32.62
Dialup Access: Telephone: +44 344 868 436
Use following settings on terminal emulator:
no parity, 8 bits, 1 stop bit, half duplex
User-id: Login: ewos
Password: ewos
Electronic Mail Addresses
X.400: s=ewos; o=concise; p=level-7 ltd; a= ; c=gb
(try a="gold 400" if a=" " does not function)
RFC-822: [email protected]
To be sent a user guide for the server, email the following message:
start
help user-guide
Automatic Delivery of Documents
-----------------------------------
If you would like all documents which appear in the tcp-ip-osi
directory to be automatically emailed to you, send a message containing
the following instructions to the Server:
start
goto /tcp-ip-osi
register new-info
If you need further help accessing the EWOS Information Server contact:
EWOS Information Server Helpdesk
Level-7 Ltd, Centennial Court, Easthampstead Road, Bracknell,
Berkshire, RG12 1YQ, UK
Telephone: +44 344 360049 Fax: +44 344 868442
X.400: S=helpdesk; O=CONCISE; P=Level-7 Ltd; A= ; C=GB (or A="GOLD
400")
RFC-822: [email protected]
-----------------------------------------------------
forwarded by:
--
Phil Royse Comms Consultant | member: The Peer Association
TUDOR HOUSE | (networking & OSI specialists)
12 Woodside Road, Purley
Surrey CR8 4LN (UK) Tel: (+44) 81 645-9868
-----------[000183][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 14:16:22 GMT From: [email protected] (Martin McCormick) To: comp.dcom.cell-relay,comp.protocols.tcp-ip Subject: Re: New IP protocol?
In article <[email protected]> [email protected] (Jerry W. Segers) writes: >Are these two <requirements> for <real time> video as real as Dale and >many in the telephony industry seem to believe? > >My understanding is that any real time video over a network will be >compressed in some way, at least to the extent needed to remove the >redundant information (e.g. MPEG). I also understand that current >compressors are required by current telephony standards to emit >constant output streams. Thus each compressor will use a relatively >large frame buffer that is filled from the output of the compression >process then emptied into the communication path at a constant rate. > >Is it not reasonable to change the approach when using a transport >method like IP that has a variable transmission rate? For example has >there been any work done along the lines of moving the buffer to the >other end of the path. That is, send the variable output from the >compressor directly to the network and collect it in a buffer at the >receiving end. If the data arrives too late or is lost, the buffer >will empty but the display software can repeat the last frame thus >causing the display to stutter then jump but the picture quality will >not degrade. The same argument would seem to apply to audio as well. >Instead of duplicating the output on buffer empty just output silence. I think that this is the basis for some of the digital cellular telephone protocols which are being developed to make most practical use of the radio spectrum which is available for this purpose. The systems use linear predictive coding to encode and decode the voice. When conversation is happening, the data rate increases to about 9600 bits/sec, but pauses while the other person is talking or while one is on hold or just thinking mean that the encoder just repeats the same background noise or silence which doesn't have nearly as much information in it and so it can drop down to a few hundred bits per second. The receiver will deliver the correct sound to the ear so a user won't even know anything has changed. I am not an engineer, nor do I play one on T.V., but there seems to be a fundamental truth that it is much easier to have a slightly dirty network than it is to have a perfect one. Everything in life, from human conversation to highway traffic has to base its operation on the idea that chaos reigns and that all we can do is make the best of an uncertain situation. I cast my lot with those who say that we should find ways to make all types of data coexist rather than engineering a new protocol each time somebody comes up with a new application. Saying all that, it is also true that networks can only stand so much degradation before everybody becomes unhappy. Big buffers won't help you at all when the gaps in throughput become to long to sustain minimum bandwidth. If this is not the case, however, then one should be able to run video, voice and anything else with no trouble at all as long as the buffers can absorb the variations in throughput which come from a busy network. I have always been most interested in protocols like TCP-IP and "Kermit" because they are based on the chaos of the real world and they work under terrible conditions. This doesn't mean that there is no room for improvement, but only that chaos is the rule and that the future belongs to whoever can best manage it. Martin McCormick WB5AGZ Stillwater, OK O.S.U. Computer Center Data Communications Group
-----------[000184][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 14:32:32 GMT From: [email protected] (Christoph Weber-Fahr [KIT]) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp.ip,comp.protocols.ppp,comp.protocols.pcnet,apana.general Subject: Re: Looking for alternative to pc-route...
Hello,
Anthony Rumble ([email protected]) wrote:
>: Does anyone know of an alternative/replacement for pc-route.
>: Be it Free, GNU, Shareware or Commercial..
^^^^^^^^^^
Ok: Novell Multi-Protocoll-Router. Basing on a Runtime Version of Novells
Netware 3.11 it has extensive ip routing capapbilities (according to what they
told me on Networld). PPP Support, Don't know about SLIP. Needs a 386sx
box minimum, and probably advanced hardware for serial connections.
BTW why not take one of the free Unix versions ? Linux ? NetBSD (or what
they call it this week) ?
>Oh.. P.S.. Don't suggest KA9Q.. It's too slow.
Well, then...
Regards
Christoph Weber-Fahr
--
Christoph Weber-Fahr | E-Mail: [email protected]
Universitaet Kaiserslautern, KIT | S-Mail: Postfach 3049
Tel. 0631/205-3391 | D-67653 Kaiserslautern
-------------------------- My personal opinion only ---------------------
-----------[000185][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1993 15:19:54 GMT From: [email protected] (Paul Bleimeyer) To: comp.protocols.tcp-ip Subject: WINQVT / PCNFS 5.0 and Hgopher
Hello, I am looking for someone who has gotten the Hgopher Client to pass the internet address and port # to their telnet session while running either pcnfs 5.0 or WinQVT 3.9x. You have to define this in the dialog for calling the telnet session when connecting to a telnet based site. Has anyone figured out how to do this? I have tried to do this under WINQVT and PCNFS but they see the environment variables as setup files. If you got this to work, could you send me the string that you put in the dialog box? regards, -- Paul Bleimeyer Mayo Foundation [email protected]
-----------[000186][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 16:33:20 GMT From: [email protected] (Martin McCormick) To: comp.protocols.tcp-ip Subject: Information Service
What is a good way to provide those who don't have accounts on this system access to certain information. We use this system as a remote print server, among other things, and we have the problem of tracking print jobs from the host which actually originated the job to the printer. When something goes wrong, there is no way for a person who does not have an account on datacomm.ucc.okstate.edu to see if their job ever got that far. For the sake of peace and quiet and a lessening of interruptions, it would be nice to provide everybody concerned with a finger-like program that they could telnet to or finger which would let them see a listing of all the printers and their statuses or even look at the emerging log file to see if their job was ever printed. Needless to say, we would only want to do this if it was possible to do it with a reasonable expectation that it could not be subverted to some other purpose for which we hadn't planned. Please let me know your ideas on this topic and I will post the best suggestions. Thank you. Martin McCormick WB5AGZ Stillwater, OK O.S.U. Computer Center Data Communications Group
-----------[000187][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 93 16:58:43 GMT From: [email protected] (Warren W. Gay VE3WWG) To: comp.protocols.tcp-ip Subject: IP Protocol RFC(s) & ftp/listserv site(s)???
Can some kind person direct me to the necessary RFC documents that I need to get the TCP & IP protocol specifications? I want to know the implementation details, packet formats, state diagrams, encoding etc. Having identified the RFCs, my next need is, a source for these. Listserv access is preferred, but I can always ftp via decwrl if I must. Can someone suggest electronic sources for the above RFC document(s)? Please email the reply. Thanks in advance. -------------------- Warren W. Gay VE3WWG John Coutts Library Services Limited [email protected] Niagara Falls, Ontario, Canada
-----------[000188][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 18:57:26 GMT From: [email protected] (Gary Heston) To: comp.protocols.tcp-ip Subject: Re: more than one interface on one net
In article <[email protected]> [email protected]edu (Matt Brin) writes: >We would like to split our local net into two parts. >Can we do this by putting a SUN with two ether interfaces >in between the two parts? Both interfaces will have different >IP addresses, but will be on the same net. We would run >arpserv to have machines trying to reach "across" this machine >use the etheraddress of this machine for their destinations. >Will the "bridge" machine know how to forward properly? Sorry, this won't work. Each NIC must be on a unique net; the software can't route between two networks that have the same network number. You'll have to subnet in order to split things up, or get a repeater and use it if your problem is length or too many connections. -- Gary Heston SCI Systems, Inc. [email protected] site admin The Chairman of the Board and the CFO speak for SCI. I'm neither.
-----------[000189][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1993 14:20:18 +0300 From: [email protected] (Oleg Orel) To: comp.protocols.tcp-ip Subject: Question to all users of libftp
Attention to all users of libftp! I wonder, if you can answer to the author of libftp on the following questions: 1. What's the name of your organisation? 2. How many people use it? 3. Which purposes do you use this library for? 4. What kind of software do you produce with it's help? 5. Which standard operations are to be added? If you found some errors in the program and fixed them, please, let me know and send me your patches. Thanks. --- Oleg Orel [email protected] -- --------------------------------------------------------------------------- | Oleg Orel, Russia, Protvino | [email protected] | | Institute of High Energy Physics | Home Phone: 49106 | ---------------------------------------------------------------------------
-----------[000190][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 19:35:13 GMT From: [email protected] (Brendan F. Forsyth) To: comp.protocols.tcp-ip Subject: Routing with SLIP
I have a machine (machA) with both SLIP and ethernet connections. The ethernet is attached to our local net and the SLIP is a connection to a terminal server attached to the internet via an Internet VAR. This local machine (machA) can connect to all systems, Internet and local, without difficulty but none of the local ethernet systems can connect to Internet systems. The local network machines all have IP addresses that are not registered with the NIC. Only the SLIP address has a valid class 'C' number assigned by the NIC. I put a serial analyzer on the SLIP connection and when a request is made from one of the ethernet machines for Internet access the source IP address field has the ethernet machine's IP address contained within. It would seem apparent that when the packet hits the other side of the SLIP connection it is getting delivered to the destination IP address but when the corresponding packet is sent back it gets lost because the return address is one that may be in use by a node on the Internet. This legitimate node then probably throws away the packet since it did not originate it. If I understand ARP correctly, hardware address and IP address are utilized to perform routing. But the SLIP connection does not use hardware addresses in its limited encapsulation scheme. Is it possible to have the SLIP connection work as a gateway/router for the local machines to connect to Internet services since a SLIP connection does not use hardware addresses in its packets to associate IP addresses with hardware addresses? If it is possible, what am is the solution to routing traffice through the SLIP connection> Any and all suggestions would be greatly appreciated. Thanks Brendan [email protected]
-----------[000191][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1993 21:05:35 GMT From: [email protected] (Nam N. Nguyen) To: comp.protocols.tcp-ip Subject: SLIP over modem line?
I and my colleagues are scratching our heads trying to make SLIP working over a modem connection. With direct cable connection, it is working fine. Now, when each end is connected to a modem, what is the proper procedure for attaching slip, using standard SunOS tools (tip, ...)? When we try to tip to make a modem connection, quitting tip causes the line to drop (NO CARRIER). NO good! If we leave tip there, slip-attach cannot access the port. Any netter has successfully done this, PLEASE help! Thanks, Nam N.
-----------[000192][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 21:13:44 GMT From: [email protected] (Wayne Johnson) To: comp.protocols.tcp-ip Subject: Re: Broadcast RPC
In article <[email protected]> [email protected] (Ben A. Mesander) writes:
>
>Hello,
>
>While developing an RPC/UDP application, I thought it would be more efficient
>to contact rpc daemons on my local network with broadcast RPC, rather than
>calling each host in turn. It would seem that if the number of hosts is n,
>then calling each host would result in 2n udp packets for every call (barring
>complications), while a broadcast scheme would involve n+1 packets - one for
>the broadcast, and n replies.
>
>However, I see that every host is responding to a clnt_broadcast() call four
>times, so I see 4n+1 packets. I have verified that the RPC libraries in SunOS
>4.1.3 and DG/UX 5.4.1 both do this. The source to clnt_broadcast() looked
>opaque to me, so I used etherfind to sniff rpc/udp on my network. When I
>make a clnt_broadcast() call, the rpc client sends out four, rather than
>one broadcast packet.
>
>Is this a bug?
I've been using clnt_broadcast() for one of our products and I found that we
transmit one packet on each one of our interfaces (loopback, and two ethernet
interfaces), but the pain is that the RPC client (also in the same box) receives
all three and replies to them. This is on a RS/6000 running AIX 3.2.4.
With all the problems we've had with this and other related things (i.e. how
not to send to certain systems where you have test software and vise versa...)
I almost wish the original writer hadn't used them.
--
Wayne D. T. Johnson Internet: [email protected] Phone: (612) 830-7880
National Computer Systems, 4401 West 76th Street, Edina, Mn. 55435
"He is no fool, who gives up what he cannot keep, for what he cannot lose"
- Jim Elliott
-----------[000193][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1993 21:24:22 GMT From: [email protected] (Dewey Paciaffi) To: comp.protocols.tcp-ip Subject: Duplicate IP Numbers
We have an environment mix of IBM workstations/servers and PCs, in a wide area Internet. Recently we've seen an increase of PCs running TCP/IP. Along with this increase has come an alarming number of duplicate IP addresses being configured into the PCs. The PCs hang until the situation is cleared up, of course. We are also able to make workstations and servers hang using PCs. Some people here are understandably distressed about this. My question is how are others in this type environment dealing with this issue, be it malicious or innocuous in intent. -- Dewey Paciaffi [email protected]
-----------[000194][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 21:34:58 GMT From: [email protected] (Steven L. Johnson) To: comp.protocols.tcp-ip Subject: Re: Routing with SLIP
[email protected] (Brendan F. Forsyth) writes: >This local machine (machA) can connect to all systems, Internet and local, >without difficulty but none of the local ethernet systems can connect to >Internet systems. The local network machines all have IP addresses that >are not registered with the NIC. Only the SLIP address has a valid class >'C' number assigned by the NIC. You have correctly identified the problem: trying to use an unregistered IP network number on the Internet. >If I understand ARP correctly, hardware address and IP address are >utilized to perform routing. But the SLIP connection does not use >hardware addresses in its limited encapsulation scheme. ARP is used to resolve addresses within an IP network, not for routing between IP networks, i.e. across the Internet. >Is it possible to have the SLIP connection work as a gateway/router for >the local machines to connect to Internet services since a SLIP connection >does not use hardware addresses in its packets to associate IP addresses >with hardware addresses? In general, yes. Use or lack of hardware addresses is not the issue. >If it is possible, what am is the solution to routing traffice through the >SLIP connection> Get a registered IP network number for your local machines. Talk to your internet service provider to determine what must be done to get packets routed to your local network via the various IP backbones. >Any and all suggestions would be greatly appreciated. Don't try and route non-registered IP addresses out onto the internet at large. At best, it won't work. At worst, it will cause headaches for some other people. -Steve
-----------[000195][next][prev][last][first]---------------------------------------------------- Date: 12 Oct 1993 22:01:56 GMT From: Colen Garoutte-Carson <[email protected]> To: comp.protocols.tcp-ip Subject: The telnet protocol
If there is another newsgroups in which I'd be more likely to get an answer, please let me know. I have written BBS software which, in addition to handling modem connections, handles telnet connections. Unfortunatly, the terminal emulation (PC-ANSI BBS) doesn't interface too well with most telnet terminals. Now, I understand that there is a way to change the settings of the remote terminal with telnet IAC sequences. Is there a way to tell the remote terminal : not to send LFs after it's CRs not to echo characters, the host will echo them back not to buffer characters on a line basis If this is at all possible, could someone give me the EXACT escape code sequence needed? I don't plan on supporting the telnet IAC sequences. All I'm doing now is responding to IACs with "Uh... I dunno how to do that" for every option they suggest, so all I want to do is send this string of IAC sequences once the telnet connection had been establish. Any help is greatly appreciated! - Colen Garoutte-Carson Please send replies to my email address : [email protected]
-----------[000196][next][prev][last][first]---------------------------------------------------- Date: Tue, 12 Oct 1993 22:06:26 GMT From: [email protected] (Subbu Subramaniam) To: comp.protocols.tcp-ip Subject: Info needed:"fail-safe" FTP
I would like to know if there is a public domain FTP that can do retries etc. while transfering files over unreliable links? I believe it is sometimes referred to "relibale" FTP. WO|uld appreciate if you can email the info to me Thanks, -Subbu Email:[email protected]
-----------[000197][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 93 10:28:11 GMT From: [email protected] (Christian Huitema) To: comp.protocols.tcp-ip Subject: Re: Is NIC running out of unique IP addresses?
In article <[email protected]>, [email protected] (Scott Larsen) writes:
|> In article <[email protected]>,
|> Tim Wynn <[email protected]> wrote:
|>
|> > One of my co-workers is in a UNIX course on TCP/IP right
|> >now, and he tells me that his instructor said that NIC is running
|> >out of unique IP addresses. Because of this, he says, NIC is
|> >calling people to ask for any unused addresses they might have
|> >requested in the past. Furthermore he said, it's next to impossible
|> >to get contiguous blocks of addresses anymore, and getting any
|> >addresses takes 6 weeks or more.
|>
|> Not true. 3 weeks ago I requested 6 type "C" addresses and they are
|> contiguous. They arrived in about 3 days.
|>
|> ...
|>
|> However, address depletion is a serious issue. According to "Supernetting:
|> an Address Assignment and Aggregation Strategy", by V. Fuller, T. Li, J. Yu,
|> and K. Varadham, all class "B" addresses could be exhausted within the next
|> 15 months, if the present rate of growth is maintained. In exchange, large
|> quantities of class "C" addresses are being given out to avoid this. This,
|> though, puts a larger load on routers, as they have larger tables to maintain.
|>
|> Current research is being done by the ROAD (Routing and Addressing) group of
|> the IETF (Internet Engineering Task Force).
|>
As Scott Larsen mentions, all of this is a serious issue, which is taken
seriously. The IAB/IESG/IETF have been working on this problem for several
years. In short, the Internet has been experiencing a rapid and sustained
growth in the past years, doubling its "size" every year or maybe faster. If
nothing had been done, the following problems would have occured:
1) exhaustion of the "class B" numbering space between 1993 and 1994,
2) explosion of the size of the routing tables,
3) exhaustion of the network numbering space between 1997 and 2004.
The ROAD working group, under the leadership of Peter Ford, analyzed these
problems and provided a set of recommendations in Spring 1992. One of the
results of these is the recommendation of the class less addressing
architecture (CIDR). The idea is to taylor address assignments to the exact
needs of the requesting organization: if you have 1000 hosts, you will get 10
or maybe 11 bits of address space (4 or 8 contiguous class C) instead of one
class B (16 bits). This is already implemented; it will make the address
utilization more efficient, and avoid the "class B exhaustion" pitfall (number
1 above).
Indeed, assigning more "class C" has the immediate effect of speeding up the
"routing table exhaustion" problem. The NSFNET tables listed 10057
configured networks by March 1993, 17092 by October 93. Out of these, 13063
were class C. The answer to this problem is to deploy the second part of CIDR,
classless routing. Suppose you have received 8 contiguous class C networks:
there is no need to represent them by 8 entries in the routing tables; a 21
bits long prefix would carry the same information. Now, suppose that assignment
of addresses somehow follows "network topology", e.g. that all networks in the
island of Tahiti are numbered out of a single range of class C addresses, with
a common 14 bits prefix: it would be sufficient to carry that prefix in the
routing tables, instead of 1000 separate networks. This will get us rid of the
second pitfall, "routing table exhaustion" -- with one condition though: we
must deploy routing protocols capables of routing on variable length masks,
like OSPF version 2, RIP version 2 or the last version of BGP.
The third danger is more difficult to avoid completely. There are currently
about 2 million hosts in the Internet. If the size of the net keeps doubling
every year, there will be more than 4 billion hosts in the net in 11 years,
and there will be no way to assign them unique numbers out of a 32 bits space.
In fact, we will very likely run out of 32 bits addresses before registering 4
billion hosts -- we don't assign address very efficiently now, and there are
many cases of a class C net with just a dozen hosts. On the other hand, nobody
has the slightest idea of future growth rates -- doubling every year for 11
years is not necessarily going to happen. As a result, the opinions of experts
vary considerably. Some think that a combination of CIDR + claiming back
unused address + renumbering when appropriate would lead us "well into the
XXIst century", while other think that the danger is more imminent and that we
should deploy relatively fast a "next generation of IP". Several working
groups are currently studying possible IP next generation designs, based on
either extending the IP address to 64 bits (SIP and PIP, TP-IX) or replacing
IP by ISO-CLNP (TUBA) -- comparing these solutions would make this message way
too long!
In the short term however, there is no such thing as an address shortage.
On CIDR, I recommend the reading of:
1520 I Y. Rekhter, C. Topolcic, "Exchanging Routing Information Across
Provider Boundaries in the CIDR Environment", 09/24/1993. (Pages=9)
(Format=.txt)
1519 PS V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain
Routing (CIDR): an Address Assignment and Aggregation Strategy",
09/24/1993. (Pages=24) (Format=.txt) (Obsoletes RFC1338)
1518 PS Y. Rekhter, T. Li, "An Architecture for IP Address Allocation with
CIDR", 09/24/1993. (Pages=27) (Format=.txt)
1517 PS R. Hinden, "Applicability Statement for the Implementation of
Classless Inter-Domain Routing (CIDR)", 09/24/1993. (Pages=4)
(Format=.txt)
1481 I C. Huitema, I. Architecture Board, "IAB Recommendation for an
Intermediate Strategy to Address the Issue of Scaling", 07/02/1993.
(Pages=2) (Format=.txt)
1467 I C. Topolcic, "Status of CIDR Deployment in the Internet",
08/06/1993. (Pages=9) (Format=.txt)
1466 I E. Gerich, "Guidelines for Management of IP Address Space",
05/26/1993. (Pages=10) (Format=.txt) (Obsoletes RFC1366)
Christian Huitema
-----------[000198][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Oct 1993 10:36:23 GMT From: [email protected] (Joe DeBiso) To: comp.protocols.tcp-ip Subject: How do I tie in remote PC's & CRT's without SLIP/PPP Maybe a "Net Modem"?
I need a way to tie in 2 remote sites that will have term servers and PC's running PCNFS. I need to be able to telnet to the host, use host printers and mount remote file systems. I have seen a net modem by Rockwell that does just this, but it's only for dialup lines at 14.4 baud. I need something to go over a leased digital line. Can anyone give me some direction? I'm very new to this area of networking, so please be easy on me!
-----------[000199][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 93 16:39:49 MDT From: [email protected] (Joshua Dinerstein) To: comp.protocols.tcp-ip Subject: HELP with TELNET options in binary mode!
Hello all,
I desprately need some help with a telnet aplication. I have been
working on a telnet port of sorts. And I have a problem. My problem is that
when I switch the telnet session into binary mode, using "set binary on" and
then try to connect to the local Unix host I am forced to enter a ^J to get the
proper username and password entered instead of just using the return key. So
I have to do:
slmt9^J
xxxxx^J
rather than
slmt9<ret>
xxxxx<ret>
In looking at the telnet code, it appears that it is just passing the
CR (\r) onto the remote end. Where the remote end is waiting for a LF (\n)
(or even a CRLF).
So my question: Is there a way to tell the remote system to react to
just a CR rather than a LF or CRLF combination? I do not want just swap the CR
and LF as this telnet client allows binary file transfers and swapping the
codes would mess this up completely.
Any help or ideas would be greatly appriciated,
Joshua
[email protected]
--
**************************************************************
* * *
* Joshua Dinerstein * Nothing matters and what if it did? *
* [email protected] * - Who Knows!!! *
* * Anyone?? Anyone?? *
**************************************************************
If it's a raincoat why does it have to be dry cleaned?
- Some Guy on some comody show
-----------[000200][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Oct 1993 11:36:30 GMT From: [email protected] (Wong Siu To) To: comp.protocols.tcp-ip,comp.unix.admin Subject: Routing on machines with 2 network interface...
Hi there, I apologize if this's a FAQ... We've a unix machine (HP9000/755) with 2 network interface connected to 2 different subnets (e.g. 137.189.6 and 137.189.7). I wonder if the machine will act as a router to route packets to and fro these 2 subnets. If the answer is yes, how can we stop that ? Would anyone pls advise ? Any help will be appreciated. Regards, -- S.T. Wong | BITNET: [email protected] Computer Services Centre | Internet: [email protected] The Chinese University of Hong Kong | Tel. No: (852) 609 8825 Shatin, N.T., Hong Kong | FAX No: (852) 603 5001
-----------[000201][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Oct 1993 11:41:06 GMT From: [email protected] (Pedro Miguel M R Marques) To: comp.protocols.tcp-ip Subject: Re: Information Service
Martin McCormick ([email protected]) wrote: : What is a good way to provide those who don't have accounts on this : system access to certain information. We use this system as a remote print : server, among other things, and we have the problem of tracking print jobs : from the host which actually originated the job to the printer. When something : goes wrong, there is no way for a person who does not have an account on : datacomm.ucc.okstate.edu to see if their job ever got that far. For the sake : of peace and quiet and a lessening of interruptions, it would be nice to : provide everybody concerned with a finger-like program that they could : telnet to or finger which would let them see a listing of all the printers : and their statuses or even look at the emerging log file to see if their : job was ever printed. : Needless to say, we would only want to do this if it was possible : to do it with a reasonable expectation that it could not be subverted to some : other purpose for which we hadn't planned. Please let me know your ideas : on this topic and I will post the best suggestions. Thank you. : Martin McCormick WB5AGZ Stillwater, OK : O.S.U. Computer Center Data Communications Group
-----------[000202][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Oct 1993 12:29:02 GMT From: [email protected] (Ian Phillipps) To: comp.protocols.tcp-ip Subject: Re: Text Descriptions with FTP's "ls" command
[email protected] (John Hascall) writes: >[email protected] (Russell Nelson) writes: >}In article <[email protected]> [email protected] writes: >} >} PS, I really love how programs like NcFTP send junk like: >} NLST -FC file >} assuming that all (unix) LIST/NLSTs are ls-based... (*sigh*) >} >}That's why the FTP protocol needs a new XLST command, which is >}guaranteed to return information in a parsable format. The obvious >}choice is the output of "/bin/ls -lg". That makes implementing XLST >}just a matter of making an alias for NLST. > ... all the world's Unix disease again ... I'm in agreement with John here. FTP servers can be running Unix, DOS, Windows NT, OS/2, VMS (several flavours of server on each of these). When I'm using an FTP server, at least the anonymous variety, I'd like to know a description. Good maintainers have README, INDEX etc - maybe there should be a preferred place and format for this info, so that clients can try to fetch it automatically. On file statistics, I do *not* usually want to know the permissions, owner or group of the file - I can get this from DIR if I need it, but it should not contain any useful information. Maybe, occasionally, I'd like to know if there's write-permission on a directory. I do like to know the size of the file, to a rough estimate if necessary, and whether it's a plain file or a directory. It's sometimes useful to know the last-modified date as well. These concepts should apply to pretty well any server. I usually do "ls -sCF" if it looks like a consenting Unix. This presents what I want to know with a minimum of screen real-estate; but I'd vote for a one-file-per-line name/size/type, with the types being plain file or directory. Maybe split "plain file" into text, binary and others - i.e. the "preferred" mode of the server when you fetch it. This, if adopted (if!) would make life a lot easier for writers of FTP client front-ends, who currently have to do some nasty heuristic grovelling to work out if that thing there is a directory, which is their main worry. Ian -- --- Ian Phillipps. Tech support manager, Unipalm. If you ask me, all conspiracy Phone +44 223 250103, Fax 250101 theories are put about by the Pipex phone +44 223 250120. Internic: IP4. same bunch of people.
-----------[000203][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 93 13:23:33 GMT From: [email protected] (Douglas Luce) To: comp.protocols.tcp-ip Subject: Re: more than one interface on one net
Gary Heston ([email protected]) wrote: : In article <[email protected]> [email protected] (Matt Brin) writes: : >We would like to split our local net into two parts. : >Can we do this by putting a SUN with two ether interfaces : >in between the two parts? Both interfaces will have different : >IP addresses, but will be on the same net. We would run : >arpserv to have machines trying to reach "across" this machine : >use the etheraddress of this machine for their destinations. : >Will the "bridge" machine know how to forward properly? : Sorry, this won't work. Each NIC must be on a unique net; the software : can't route between two networks that have the same network number. : You'll have to subnet in order to split things up, or get a repeater : and use it if your problem is length or too many connections. It might work: for each machine you add to the network, a static route can be put on the Sun, and a proxy ARP entry as well. This will make the sun respond to ARP requests for certain machines, and then be able to route packets that come in for that machine. It requires that every host you add to the network gets a route and proxy ARP entry on the Sun. If you want to exercise fascist control, this is doable, but for convenience, it's pretty unwieldy. If you just want to tie two nets together, a bridge is probably what you want. (Maybe Sun has a product that'll turn a Sun station into a bridge?) Doug Luce Duquesne University CCIT
-----------[000204][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Oct 1993 13:25:32 GMT From: [email protected] (Hooshmand Afsar-zadeh) To: comp.protocols.tcp-ip Subject: Is there an application for dumping tcp-ip packets
I am looking for a way to write the data that is being received by a proprietary database application (via tcp/ip) to a logfile in order to use that data to populate a database on a pc for novice users. I am looking for an application that allows me to intercept the data stream and if possible even do more things like parsing out the packet headers and creating a data file. The hardware is an HP workstation. I have heard of tcpdump, how can I get it? Is there anything better or more complete available? Thanks in advance. Regards, hOOsh*
-----------[000205][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Oct 1993 14:06:43 GMT From: [email protected] (Lance Speelmon) To: comp.protocols.tcp-ip,comp.protocols.ppp Subject: Re: IPX via SLIP/PPP?
We are doing IPX tunneling here with FTP's PCTCP 2.2. Novell's LAN Workplace for DOS also includes the tunneling drivers. Both packages support slip and ppp. Lance In article <[email protected]> [email protected] (Ted Morris) writes:>From: [email protected] (Ted Morris) >Subject: IPX via SLIP/PPP? >Date: 12 Oct 1993 08:25:48 -0400 >Our University is instituting SLIP access through Zyplex multiprotocol >terminal servers. A project I'm working on is going to install the >"same" equipment so they can be managed together. PPP is not planned >immediately but is an option with this server. >Supposedly, it ought to be possible to "tunnel" IPX packets through IP; >I think I've also heard that upcoming Novell releases will allow the use >of TCP or IPX to move the Novell information (?)... >Has anyone -successfully- put a pc running IPX/NETx in touch with a >remote Novell server through a SLIP or PPP connection to the Novell's >LAN? I recognize that 1) the Novell server must be running TCP/IP in >some flavor (LAN Workplace?), 2) the pc must be running both TCP/IP and >IPX (LAN Workplace again?) (at present), and 3) the pc must be running a >SLIP or PPP package and communicating with a suitable SLIP/PPP server on >the same internetwork as the Novell server. >From what we've read, we think this -could- be do-able, but haven't >heard of any successful installations yet. We want to make our remotely >connected pcs both nodes on the TCP/IP network and clients of the Novell >server, basically, so they can run some of the Novell-stored MS-DOS/etc. >software. (Yes, we know that will be slow...) >Thanks for any comments/suggestions/pointers. >Theodore Allan (Ted) Morris, University of Cincinnati Medical Center, >513-558-0177V, -2682F, [email protected], [email protected], WB8VNV >Previous politically-incorrect tag-line removed. ============================================================================ | Lance Speelmon | University Computing Services | | [email protected] | LAN Systems Support Specialist | ============================================================================
-----------[000206][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Oct 1993 15:03:35 GMT From: [email protected] (Christoph Weber-Fahr [KIT]) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp.ip,comp.protocols.ppp,comp.protocols.pcnet,apana.general Subject: Re: Looking for alternative to pc-route...
Hello, following up om myself... [email protected] (Christoph Weber-Fahr [KIT]) writes: >Anthony Rumble ([email protected]) wrote: >>: Does anyone know of an alternative/replacement for pc-route. >>: Be it Free, GNU, Shareware or Commercial.. > ^^^^^^^^^^ >Ok: Novell Multi-Protocoll-Router. Basing on a Runtime Version of Novells >Netware 3.11 it has extensive ip routing capapbilities (according to what they >told me on Networld). PPP Support, Don't know about SLIP. Needs a 386sx >box minimum, and probably advanced hardware for serial connections. Another one: I just saw an ad (sort of) for a packet driver based software router from IPSWICH software. It seems to be rather inexpensive, and, since it was specifically advertized for dual channel ISDN routing, it should be able to process that kind of speed. >BTW why not take one of the free Unix versions ? Linux ? NetBSD (or what >they call it this week) ? That question seems to remain unanswered. Regards Christoph Weber-Fahr -- Christoph Weber-Fahr | E-Mail: [email protected] Universitaet Kaiserslautern, KIT | S-Mail: Postfach 3049 Tel. 0631/205-3391 | D-67653 Kaiserslautern -------------------------- My personal opinion only ---------------------
-----------[000207][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 1993 15:12:31 GMT From: [email protected] (Dewey Paciaffi) To: comp.protocols.tcp-ip,comp.unix.aix Subject: Static Arp Tables
I was experimenting with the arp command under AIX 3.2.[2-4]. The FM lead me to believe that the "arp -s" command could create a "permanent" table entry. My test showed that if a system with a hardware address different from the one in the permanent arp entry logged in, the system with the entry would cache the new hardware address, leaving the entry marked "permanent". Does "permanent" in this case mean "won't be dynamically dropped" or "will never change" ? If it's the latter, then my arp is broken. -- Dewey Paciaffi [email protected]
-----------[000208][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 1993 15:16:34 GMT From: [email protected] (Dewey Paciaffi) To: comp.protocols.tcp-ip Subject: RARP
I have remote PCs accessing Unix machines across the wide area through Cisco routers. Can RARP work through routers? -- Dewey Paciaffi [email protected]
-----------[000209][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 1993 15:17:31 GMT From: [email protected] (Paul Douglas) To: comp.protocols.tcp-ip Subject: TCP-IP freeware for 68k?
Hi Everyone, I'm looking for TCP-IP freeware (or low-costware) that will run or can be easily ported to a 68k system running pSOS. Does anyone out there know of such software? Thanks, Paul [email protected]
-----------[000210][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 1993 16:38:54 GMT From: [email protected] (Antonis Kyriazis) To: comp.protocols.tcp-ip Subject: Re: Routing on machines with 2 network interfa
I think there is a 'gated' program on HPs. Just follow the directions on how to build the /etc/gated.conf (man gated-config). +-------------------------------------------------------------------+ | Antonis Kyriazis | | Networks & Communications e-mail: [email protected] | | INTRACOM sa | | 19.5 km Marcopoulo Ave. fax: +30-1- 66 44 379 | | Peania 190 02 +30-1- 66 43 718 | | GREECE phone: +30-1- 66 44 961-5 | | +30-1- 88 43 715 | | "The expressed opinions are of my own" + - MACEDONIA IS GREEK - + +-------------------------------------------------------------------+
-----------[000211][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 1993 17:45:35 GMT From: [email protected] (David Addison) To: comp.protocols.tcp-ip Subject: Re: Routing on machines with 2 network interfaces
For Solaris 1.x and Solaris 2.x I think the answer is yes, packets will be forwarded automatically between the two networks. This forwarding is performed inside the kernel and does not require a daemon. To disable it you need to set the kernel IP variable 'ip_forwarding' to 0. Don't know how you do that on a HP - sorry!. Addy. --- David Addison Email: [email protected] Meiko, or: [email protected] 650 Aztec West, Tel : +44 (0)454 616171 BRISTOL, BS12 4SD. Fax : +44 (0)454 618188
-----------[000212][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Oct 1993 18:16:48 GMT From: [email protected] (hwajin bae) To: comp.protocols.tcp-ip Subject: Re: TCP-IP freeware for 68k?
In article <[email protected]> [email protected] (Paul Douglas) writes: > > I'm looking for TCP-IP freeware (or low-costware) that will >run or can be easily ported to a 68k system running pSOS. > >Does anyone out there know of such software? i don't know about pSOS but i've done ports of various versions of BSD TCP/IP, including net-2 BSD code. the net-2 code works well and can be easily ported to a simple RTOS (i'm working on a free port of this to my own RTOS for 68k, so stay tuned...) i know.... vaporware alert! ;-) hwajin
-----------[000213][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Oct 1993 19:39:36 GMT From: [email protected] (Marshall Wilensky) To: comp.protocols.tcp-ip Subject: What characters are illegal in a TCP/IP hostname?
What characters are illegal in a TCP/IP hostname? If it's easier, answer the
converse question: Which special characters are legal? I'm only concerned
with the printing US ASCII characters found on most keyboards.
I've been looking for a while and haven't been able to find a definitive
answer. Is there a formal definition for hostname? Even a pointer to an
appropriate RFC or FAQ would help.
Before anyone goes off the deep end, I'm not planning to start using bizarre
system names. I know that various command line interpreters have their own
ideas about what these characters mean and I've also spent enough time with
sendmail.cf files to realize that special characters should be avoided almost
at all costs. But I still need to know.
Here's what I have so far:
space ( ) ILLEGAL
exclamation point (!)
at sign (@)
pound sign (#)
dollar sign ($)
per cent (%)
caret (^)
ampersand (&) ILLEGAL
asterisk (*)
left parenthesis (()
right parenthesis ())
hyphen (-) LEGAL
underscore (_)
equal sign (=)
plus sign (+)
backslash (\)
vertical bar (|)
left bracket ([)
left brace ({)
right bracket (])
right brace (})
semicolon (;)
colon (:)
apostrophe (')
quotation mark (")
back quote (`)
tilde (~)
comma (,)
less than (<)
period (.)
greather than (>)
slash (/)
question mark (?)
Thanks in advance.
--
Marshall Wilensky [email protected]
Lotus Notes Technical Support
Lotus Development Corporation Voice +1 617 693 1810
55 Cambridge Parkway FAX +1 617 693 5561
Cambridge, MA 02142
-----------[000214][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Oct 93 20:22:53 GMT From: [email protected] (Brad Hedstrom) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: FTP PC/TCP 2.2, Windows 3.1 and remote printing
On 7 Oct 1993 15:50:36 GMT, [email protected] () said: >Remote printing under DOS seems to work fine using 'lpr' command. >But when trying to access remote printers via windows apps, it just >doesn't behave itself. >I have gone through the setup procedure several times- under FTp Network >Icon, then to printers, I setup a host:printer, username=nobody, type=pcnfs >port=lpt2, then I connect, and everything seems to be OK. Make sure that you're not running the kernel in extended memory. Also make sure that you have the correct EMMExclude in you system.ini for your NIC. >When I print I get several different results- the main one being that I >get nothing, but I have another strange effect, The PC (Windows) will hang >for about 30 seconds, and the speaker emits a click noise about every >5 seconds. Sounds like your using NFS printing. Try switching to LPR. Also get version 2 of PCNFSD. I've had both LPR and NFS printing under Windows working fine (using the 3c503 kernel). -- _________________________________________________________________________ Brad Hedstrom, Ph.D. Internet: [email protected] Consultant in DSP, LabVIEW, Networking, Sun, Macintosh, and now PCs
-----------[000215][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 1993 22:53:22 GMT From: [email protected] (Mark Fullmer) To: comp.protocols.tcp-ip Subject: Re: Duplicate IP Numbers
In article <[email protected]> [email protected] (Dewey Paciaffi) writes: >We have an environment mix of IBM workstations/servers and PCs, >in a wide area Internet. Recently we've seen an increase of PCs running >TCP/IP. Along with this increase has come an alarming number of >duplicate IP addresses being configured into the PCs. If you you have a unix box on your network capable of running tcpdump, take a look curiosity.cob.ohio-state.edu:/pub/arpmon/* (anonymous ftp). >-- >Dewey Paciaffi >[email protected] -- mark [email protected]
-----------[000216][next][prev][last][first]---------------------------------------------------- Date: 13 Oct 1993 23:05:31 GMT From: [email protected] (Tony Li) To: comp.protocols.tcp-ip Subject: Re: RARP
In article <[email protected]> [email protected] (Dewey Paciaffi)
writes:
I have remote PCs accessing Unix machines across the wide area through
Cisco routers. Can RARP work through routers?
Currently, RARP must be bridged through the routers....
Tony
-----------[000217][next][prev][last][first]---------------------------------------------------- Date: Wed, 13 Oct 1993 23:40:46 GMT From: [email protected] (Craig Partridge) To: comp.protocols.tcp-ip Subject: re: What characters are illegal in a TCP/IP hostname?
> What characters are illegal in a TCP/IP hostname?
In general, starting with RFCs 1122 and 1123 for host related issues is the
best approach (nearly equivalent to a FAQ). And sure enough, RFC 1123, p. 13
says:
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.
Host software MUST handle host names of up to 63 characters and
SHOULD handle host names of up to 255 characters.
and RFC 952, p. 1 says
1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period....
Note that RFC1123 supercedes RFC 952 on name length as well as use of
digits.
Craig
-----------[000218][next][prev][last][first]---------------------------------------------------- Date: 14 Oct 1993 11:49:31 -0700 From: [email protected] (Lon Stowell) To: comp.protocols.tcp-ip,comp.unix.admin Subject: Re: Routing on machines with 2 network interface...
In article <[email protected]> [email protected] (Wong Siu To) writes: >Hi there, > >I apologize if this's a FAQ... > >We've a unix machine (HP9000/755) with 2 network interface connected to >2 different subnets (e.g. 137.189.6 and 137.189.7). I wonder if the >machine will act as a router to route packets to and fro these 2 >subnets. If the answer is yes, how can we stop that ? > If there is no typographic error in your posting, host IP addresses 137.189.6 137.189.7 would be two different hosts on the same IP network. Depending on implementation, you may have some "interesting issues on your hands. Is that really the IP addresses? What's your netmask?
-----------[000219][next][prev][last][first]---------------------------------------------------- Date: 14 Oct 1993 00:32:41 GMT From: [email protected] (J. D. La Coursiere [Jeff]) To: comp.protocols.tcp-ip,comp.unix.admin Subject: Re: Routing on machines with 2 network interface...
In article <[email protected]>, [email protected] (Wong Siu To) writes: > Hi there, > > I apologize if this's a FAQ... > > We've a unix machine (HP9000/755) with 2 network interface connected to > 2 different subnets (e.g. 137.189.6 and 137.189.7). I wonder if the > machine will act as a router to route packets to and fro these 2 > subnets. If the answer is yes, how can we stop that ? > > Would anyone pls advise ? Any help will be appreciated. > > Regards, > > -- > S.T. Wong | BITNET: [email protected] > Computer Services Centre | Internet: [email protected] > The Chinese University of Hong Kong | Tel. No: (852) 609 8825 > Shatin, N.T., Hong Kong | FAX No: (852) 603 5001 Hmm. The answer to this depends on your control over the machines in both subnets. If you want the HP to be able to talk to machines on both subnets, then you will have routes to pass packets to each ethernet card. If you disable the routes on the other machines so they can't resolve external addresses (flush the table, kill routed, add static route for appropriate subnet ONLY), then they will give a message like: "no route to host" when told to connect to an outside machine. You didn't mention if the subnets had other gateways to escape the subnet. If this is the case, you should add a default route on each machine pointing to the desired gateway (as well as flushing the table, killing routed). The first option will allow the machines to talk to all others on the subnet (including the HP) but nothing outside the subnet. The second option (if another gateway exists) will allow full communication for all hosts but all packets destined to outside hosts will NOT be routed through the HP. If you don't have this kind of control over the machines in both subnets, there is nothing to stop them from adding you as a default gateway to the other subnet. The HP, receiving a packet that it knows how to pass on, will gladly do so. Jeff LaCoursiere Network Admin Mobil Research Facility Dallas, TX [email protected]
-----------[000220][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 02:27:54 GMT From: [email protected] (Brendan Forsyth) To: comp.protocols.tcp-ip Subject: Re: Routing with SLIP
Steven L. Johnson ([email protected]) wrote: : [email protected] (Brendan F. Forsyth) writes: : >This local machine (machA) can connect to all systems, Internet and local, : >without difficulty but none of the local ethernet systems can connect to : >Internet systems. The local network machines all have IP addresses that : >are not registered with the NIC. Only the SLIP address has a valid class : >'C' number assigned by the NIC. : You have correctly identified the problem: trying to use an : unregistered IP network number on the Internet. A proper routing config will protect the Internet from erroneous traffic. : Get a registered IP network number for your local machines. : Talk to your internet service provider to determine what : must be done to get packets routed to your local network : via the various IP backbones. Getting a registered number for over 50 nodes and then reconfiguring each is not a feasible solution. Once again could we open a discussion of routing and SLIP connections? I am sure that I am not the only one experiencing this problem. Thanks Brendan
-----------[000221][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 04:35:41 GMT From: [email protected] (David P. Maynard) To: comp.protocols.tcp-ip Subject: IP header checksum calculation
I known I am missing something obvious here. I am trying to write a
routine that computes an IP header checksum. I have read both Comer's
book and RFC791.
Here is Comer's description of the checksum calculation:
"The IP checksum is formed by treating the header as a sequence of
16-bit integers (in network byte order), adding them together using
one's complement arithmetic, and then taking the one's complement of
the result. For purposes of computing the checksum, field HEADER
CHECKSUM is assumed to contain zero."
Here is the tcpdump output for a random packet off my network (taken
on a i486 NetBSD box):
22:15:24.38 clave.depend.com.login > archons.depend.com.1023: P 1:28(27) ack
0 \win 7300 [tos 0x10]
4510 4300 cd02 0000 3c06 565d c6bb cc02
c6bb cc01 0102 ff03 0100 0000 0000 0000
5018 841c f90f 0000 7463 7064 756d 703a
206c 6973 7465
The IP header is 5<<2 = (20 octets) = (10 16-bit words) long. The
checksum field is the 6th 16-bit word (0x565d).
No matter what I try, I cannot reproduce the correct checksum. I
tried doing it by hand. I tried writing my own algorithm and
executing it. I even tried extracting the code from in_cksum.c in the
NetBSD sources. The "sum" I get is 0x496a (or 0x6a49 if I byte-swap).
What am I doing wrong?
Thanks,
David
(feeling really dumb at the moment)
--
David P. Maynard, Carnegie Mellon University & Dependable Solutions
USMail: 14312 Richard Walker Blvd, Austin, TX 78728-6862
EMail: [email protected], Tel: +1 512 251 8122, Fax: +1 512 251 8308
--
-----------[000222][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 07:44:49 GMT From: [email protected] (Chris Dalton) To: comp.protocols.tcp-ip Subject: Re: IP header checksum calculation
David P. Maynard wrote:
| I known I am missing something obvious here. I am trying to write a
| routine that computes an IP header checksum. I have read both Comer's
| book and RFC791.
It's not that obvious, so don't feel bad. The problem is that tcpdump
is lying through its miserable teeth. To be more accurate, it has
presented certain fields - 16 and 32 bit numbers - in the IP header
with the wrong byte-ordering, but others (such as the checksum)
are all right. I guess someone thought this was a feature.
| 22:15:24.38 clave.depend.com.login > archons.depend.com.1023: P 1:28(27) ack
| 0 \win 7300 [tos 0x10]
| 4510 4300 cd02 0000 3c06 565d c6bb cc02
| c6bb cc01 0102 ff03 0100 0000 0000 0000
| 5018 841c f90f 0000 7463 7064 756d 703a
| 206c 6973 7465
If this were presented in network byte order, it would look like this:
4510 0043 02cd 0000 3c06 565d c6bb cc02
c6bb cc01
The checksum of that comes out OK. The TCP header also looks badly
garbled: the source port, destination port, sequence, acknowledgement,
and window fields are all wrong-endian.
Chris
-----------[000223][next][prev][last][first]---------------------------------------------------- Date: 14 Oct 1993 16:25:06 -0500 From: ILJACOB%[email protected] (Eduardo Jacob) To: comp.protocols.tcp-ip Subject: telnet ^M + ^J problem
I have a problem with my telnet for IBM PC. When I type something and
press ENTER (^M), if I press ^J right after, the host doesn't answer to the ^J.
The host seems to "ignore" a ^J (LF) after a ^M (CR). ^J after ^J is OK. Does
this happen due to some parameter my telnet isn't negociating with the host
telnet ?
Another question : does anybody know of a free ftp server source
code ?
Please, reply to the following email address (not to me !) :
[email protected]
Thanx in advance.
-----------[000224][next][prev][last][first]---------------------------------------------------- Date: 14 Oct 93 15:32:10 From: [email protected] (Dale R. Worley) To: comp.protocols.tcp-ip Subject: Re: What characters are illegal in a TCP/IP hostname?
In article <[email protected]> [email protected] (Marshall Wilensky) writes:
What characters are illegal in a TCP/IP hostname? If it's easier,
answer the converse question: Which special characters are legal?
I'm only concerned with the printing US ASCII characters found on
most keyboards.
The short answer is: Hyphen ("_") is allowed (but not as a leading or
final character), and period (".") is allowed (but has special
meaning, of course).
RFC 1034 has this to say:
3.5. Preferred name syntax
The DNS specifications attempt to be as general as possible in the rules
for constructing domain names. The idea is that the name of any
existing object can be expressed as a domain name with minimal changes.
However, when assigning a domain name for an object, the prudent user
will select a name which satisfies both the rules of the domain system
and any existing rules for the object, whether these rules are published
or implied by existing programs.
For example, when naming a mail domain, the user should satisfy both the
rules of this memo and those in RFC-822. When creating a new host name,
the old rules for HOSTS.TXT should be followed. This avoids problems
when old software is converted to use domain names.
[...]
Note that while upper and lower case letters are allowed in domain
names, no significance is attached to the case. That is, two names with
the same spelling but different case are to be treated as if identical.
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.
RFC 1178 has some further useful advice. (Including the non-obvious:
Don't choose names consisting solely of legitimate hexadecimal
digits.)
Dale
Dale Worley Dept. of Math., MIT [email protected]
--
Nothing frustrates me more than the twentieth century adherence to the
notion that you can find out what "actually happened" and that it is
necessary for fiction to set out a linear, quantitative and absolute
reality for the reader's consumption and assurance.
I think EVERYTHING is like the Kennedy assassination(s); riddled with
inconsistencies, false trails overlapping stories and considerations;
distortions wrapped inside fabrications and coated with lies. The
sooner we get over the idea that reality isn't like this, the sooner
we'll be able to put together a world that fits our circumstances as
they are; not as they never were and will never be. I'm not holding my
breath.
-- Dave Sim
-----------[000225][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 11:16:43 GMT From: [email protected] (Steven Vincent) To: comp.sys.novell,comp.dcom.lans,comp.protocols.tcp-ip Subject: Re: Novell & Banyan & TCP/IP
[email protected] (S. Khai Mong) writes: >I have this application which uses Novell's TCP/IP API and compiled >and linked with Novell's TCP/IP product. This works fine on >Novell client workstations. >My question: Is there a chance that such an application will run on a >client workstation that has _only_ Banyan and Banyan's TCP/IP software >installed? Is there any quick answer why it won't work? (I am >thinking of getting Banyan's TCP/IP software) No chance since the API calls are specific to the Novell TCP/IP stack. A windows application that is compiled to run over the Windows Sockets API will run over most TCP/IP stacks but otherwise you will need to compile and link your application with a Development kit appropriate to the TCP/IP stack you will be using. (There are many ways to run multiple protocol stacks on one card, the golden rule is only one of each type. So you can run Banyan+TCP/IP+Netware from the same box but cannot run (for instance) Lan Workplace (TCP/IP) with PC-NFS (TCP/IP). Which drivers you use for the card may make this easy or difficult and WILL affect performance and Memory consumption. I have been burnt by several of the other TCP/IP stacks mentioned in this tread concerning RAM usage and reliability. Personally I get on with PC/TCP which is what Banyan OEMs. If you want concurrency over NDIS or ODI then Lan Workplace should work with Banyan, if you need encapsulation PC/TCP from Banyan is your only option. Since I have never worked on a Banyan site I will not offer any recommendations that might mislead. >-- >Sao Khai Mong Applied Dynamics, 3800 Stone School Road, Ann Arbor, MI 48108 >Voice: (313) 973-1300x263 Fax: (313) 668-0012 E-mail: [email protected]
-----------[000226][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 12:02:38 GMT From: [email protected] (John Hascall) To: comp.protocols.tcp-ip Subject: Re: Text Descriptions with FTP's "ls" command
[email protected] (Ian Phillipps) writes: }[email protected] (John Hascall) writes: }>[email protected] (Russell Nelson) writes: }>}That's why the FTP protocol needs a new XLST command, which is }>}guaranteed to return information in a parsable format. The obvious }>}choice is the output of "/bin/ls -lg". That makes implementing XLST }>}just a matter of making an alias for NLST. }> ... all the world's Unix disease again ... }I'm in agreement with John here. FTP servers can be running Unix, DOS, }Windows NT, OS/2, VMS (several flavours of server on each of these). }On file statistics, I do *not* usually want to know the permissions, }owner or group of the file - I can get this from DIR if I need it, but }it should not contain any useful information. One possible use for permissions would be to set them the same (this would be most useful when "get"ing between same-kind machines, say, to set the execute bit). ftp> get foomatic RETR foomatic (file xfer) XMOD foomatic (sets permission bits on local copy just retrieved) ftp> John -- John Hascall ``An ill-chosen word is the fool's messenger.'' Systems Software Engineer Project Vincent Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551
-----------[000227][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 12:35:42 GMT From: [email protected] (Chris Davies) To: comp.protocols.tcp-ip Subject: Re: Can FTP's PC/TCP coexist with MS Win. for WG?
Ian Leveson ([email protected]) wrote:
: I've just tried installing Microsoft's Windows for Workgroups on a PC which
: already has access to a unix server via FTP PC/TCP's NFS utilities. Has
: anyone managed to retain access to the TCP/IP network at the same time as
: connecting the PC to others via Windows for Workgroups?
Yes.
: If so, how?
I installed WfW on a PC which already had PC/TCP and it all worked
together seamlessly - much to my utter amazment. However, this is
probably because I was already using PC/TCP over NDIS (which WfW
appears to understand).
Email me and I'll try to give real dirty specifics...
Chris
--
VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
Tel +44 532 788858. Fax +44 532 304676. Email [email protected]
-------- "VisionWare: The home of DOS/SQL/UNIX/X/VMS integration" --------
-----------[000228][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 14:57:26 GMT From: [email protected] (Steven Wayne Hudson) To: comp.protocols.tcp-ip Subject: FAQ request
Could someone please post a email this group's FAQ? I would greatly appreciate it. --- Steve Hudson /// [email protected] (0 0) -----------------------------ooO-(_)-Ooo---------------------------------
-----------[000229][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 15:15:19 GMT From: [email protected] (michael.v.murphy) To: comp.protocols.tcp-ip Subject: Networking references
A few months ago someone posted a great listing of recommended reading. I misplaced (erased?) it. Any help would be appreciated... [email protected]
-----------[000230][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 16:47:55 GMT From: [email protected] (Dave Dilena) To: comp.protocols.tcp-ip Subject: Testing a TCP/IP Implementation
Hello TCP/IP group: I'm attempting do determine how to verify my company's TCP/IP implementation. I would like to be able to establish a dialogue with the System Under Test and proceed to fragment datagrams into small pieces and verify that our TCP/IP can re-assemble properly, and perhaps send fragments out of order. I might also have the test TCP/IP cause a datagram to be fragmented so I can verify that the algorithm is correct. I'd also like to be able to drop TCP packets, say every 100th packet to determine the response to error conditions. I've been looking into protocol analyzers and testers, but many don't have the programmability necessary to perform some of these types of tests. Is my only recourse to build a programmable TCP/IP and use a packet driver on a PC to enable this type of dialogue? HELP! Thanks, Dave [email protected] Tandem Computers Corp. 18922 Forge Dr. Cupertino, Ca 95014 MS 216-51
-----------[000231][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 17:53:25 GMT From: [email protected] (Rennie Allen) To: comp.protocols.tcp-ip Subject: Re: Routing with SLIP
In <[email protected]> [email protected] (Brendan Forsyth) writes: >Steven L. Johnson ([email protected]) wrote: [munch..] >Getting a registered number for over 50 nodes and then reconfiguring each >is not a feasible solution. 1. You do not need to obtain 50 class 'C' addresses. You already have a class 'C' address, you can assign the host portion of the address as you see fit. 2. Reassigning 50 addresses is a pain in the butt, but that's why the NIC issues addresses without having to be on the internet, so that when you do go on the net, you don't have to do this. So reassigning addresses is a feasible solution, it is the only reasonable solution. >Once again could we open a discussion of routing and SLIP connections? >I am sure that I am not the only one experiencing this problem. The issue you originally raised has nothing to do with routing or SLIP connections. Your IP forwarding is working (you saw the packets with your protocol analyser), you are sending unregistered (and possibly conflicting addresses) out on the Internet. This is naughty. The original followup still stands... email: [email protected] mail: Expert Technology Corporation QUICS: rgallen (613) 591-0934 34 Riverstone Rd. Voice: (204) 339-8005 Winnipeg, Manitoba, Canada R2V 4B2 Fax: (204) 488-5943
-----------[000232][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 18:01:20 GMT From: [email protected] (Peter Karrer) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: IP address 224.0.0.5 ?
It seems that our Cisco routers talk to each other sending broadcasts with a destination IP address of 224.0.0.5 (protocol 89). What is this? The reason why I ask is that one TCP-IP package (WinQVT/Net 3.93) has recently started to complain about "invalid destination addresses", obviously as a reaction to these broadcasts. I'll send a bug report to QPC software, but I'd also like to include suggestions how to handle these "invalid" addresses. So, what's the proper way to do it? Ignore them, or complain only about certain 224+ addresses, perhaps those without 0 components? -- Peter Karrer [email protected]
-----------[000233][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 18:02:53 GMT From: [email protected] (Michael Morse) To: comp.protocols.tcp-ip Subject: Telnet to outgoing modem pool
I will be setting up a dial-out modem pool shortly, using a 3Com terminal server. The idea is that PC users will use Telnet to get to the terminal server, and from there, connect to one of the modems for dial-out. I know this is not an unusual configuration, but I would still like to learn from the collected wisdom out there. Do you have any configuration hints, gotcha's etc., you could share? --Mike Michael Morse Internet: [email protected] National Science Foundation BITNET: [email protected] 1800 G St. N.W. Room 401 Telephone: (202) 357-7659 Washington, D.C. 20550 FAX: (202) 357-7663
-----------[000234][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 21:20:43 GMT From: [email protected] (michael.v.murphy) To: comp.protocols.tcp-ip Subject: Cisco router security
Is it possible to restrict traffic on Cisco brouters by more than subnet filters? I need to restrict ftp traffic between two machines between two machines on two different nets, without completely disabling ftp on either. Our security folks say its not enough to retrict with ftp.users. Any brouter gurus out there?? Many Thanks, Mike Murphy [email protected]
-----------[000235][next][prev][last][first]---------------------------------------------------- Date: 14 Oct 1993 21:25:21 GMT From: [email protected] (Tony Li) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: IP address 224.0.0.5 ?
In article <[email protected]> [email protected] (Peter
Karrer) writes:
It seems that our Cisco routers talk to each other sending broadcasts with
a destination IP address of 224.0.0.5 (protocol 89). What is this?
OSPF
The reason why I ask is that one TCP-IP package (WinQVT/Net 3.93) has
recently started to complain about "invalid destination addresses",
obviously as a reaction to these broadcasts. I'll send a bug report
to QPC software, but I'd also like to include suggestions how to handle
these "invalid" addresses.
They should ignore them.
So, what's the proper way to do it? Ignore them, or complain only about
certain 224+ addresses, perhaps those without 0 components?
In fact, if you have a decent ethernet adapter, the correct thing to do is
to ignore multicasts that you aren't expecting. The next best thing to do
is to ignore them based on their IP address...
Tony
-----------[000236][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 22:30:52 GMT From: [email protected] (Robert Beer) To: comp.protocols.tcp-ip Subject: Re: Static Arp Tables
In article <[email protected]>, [email protected] (Dewey Paciaffi) wrote: > I was experimenting with the arp command under AIX 3.2.[2-4]. The > FM lead me to believe that the "arp -s" command could create a > "permanent" table entry. My test showed that if a system with > a hardware address different from the one in the permanent arp > entry logged in, the system with the entry would cache the new hardware > address, leaving the entry marked "permanent". > > Does "permanent" in this case mean "won't be dynamically dropped" > or "will never change" ? If it's the latter, then my arp is > broken. The perm parameter gets you an RARP. --- Bob Beer, Ohio Northern Univ., Academic Computer Services, Ada, OH 45810 [email protected]
-----------[000237][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 22:30:55 GMT From: [email protected] (Art Berggreen) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: IP address 224.0.0.5 ?
In article <[email protected]> [email protected] (Peter Karrer) writes: >It seems that our Cisco routers talk to each other sending broadcasts with >a destination IP address of 224.0.0.5 (protocol 89). What is this? OSPF (probably router Hellos) IP multicast. >The reason why I ask is that one TCP-IP package (WinQVT/Net 3.93) has >recently started to complain about "invalid destination addresses", >obviously as a reaction to these broadcasts. I'll send a bug report >to QPC software, but I'd also like to include suggestions how to handle >these "invalid" addresses. These should only be going out on the MAC multicast of 1-0-5E-0-0-5. If they are being sent to the MAC broadcast, check with Cisco. If they are using the the correct multicast, you host software shouldn't see them, so complain to the host software vendor. >So, what's the proper way to do it? Ignore them, or complain only about >certain 224+ addresses, perhaps those without 0 components? IP multicasts that are not of interest should be ignored. > >-- >Peter Karrer [email protected] Art
-----------[000238][next][prev][last][first]---------------------------------------------------- Date: 14 Oct 1993 23:01:39 GMT From: [email protected] (Tony Li) To: comp.protocols.tcp-ip Subject: Re: Cisco router security
In article <[email protected]> [email protected] (michael.v.murphy) writes:
Is it possible to restrict traffic on Cisco brouters by more than
subnet filters? I need to restrict ftp traffic between two machines between
two machines on two different nets, without completely disabling ftp on
either. Our security folks say its not enough to retrict with ftp.users.
Any brouter gurus out there??
Yes, this is relatively easy. You want to look at extended access lists.
If you have problems, please contact your appropriate support channel.
Tony
-----------[000239][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 23:03:27 GMT From: [email protected] (Eric Hunter) To: comp.protocols.tcp-ip Subject: TCP-IP for SysVR3 on NCR Tower32
I'm currently running AT&T UNIX SYS V R.3 on an NCR Tower32/650, and to
the best of my knowledge, it does not include TCP-IP. Would it be possible
to install it, and if so where could I obtain the required software/hardware?
Thanks, (in advance)
Eric Hunter
-----------------------------------------------------------------------
[email protected] | Duct tape is like The Force;
{rutgers}!sunybcs!oswego!hunter | it has a Light Side, and a Dark Side,
[email protected] | and it holds the universe together
-----------[000240][next][prev][last][first]---------------------------------------------------- Date: Thu, 14 Oct 1993 23:23:39 GMT From: Dan Lacey <[email protected]> To: comp.protocols.tcp-ip Subject: Registering IP Addresses
I would like to obtain my very range of IP addresses. How do I get them? I assume the NIC, but what is the post office or Email address I use to get an application?
-----------[000241][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 93 01:46:31 GMT From: [email protected] (TISP-Group*Shingo Tanaka(1992)) To: comp.protocols.tcp-ip Subject: Help!!! Host names and Community names
Hi,
I was wondering if some kindly soul could help me out on a
very basic question. What is the longest hostname and community
name that can be assigned (in terms of number of characters)?
Is this value machine dependent?
Any comments will be greatly appreciated.
Thank You
Shingo Tanaka
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~I have many opinions but I doubt if my company will share in them and~
~ vice-versa ! Shingo Tanaka at [email protected] ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------[000242][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Oct 1993 02:04:28 GMT From: [email protected] (Bleys Ahrens) To: comp.protocols.tcp-ip Subject: IP Addressing Program/Database
We are looking for a shareware or public domain program we can FTP from somewhere that will assist us with address assignments for a large internet created from a class B address. We would like to be able to plug in our class B address 167.11X and a default mask of 255.255.255.192 and have the program generate a flat file or database file with all the acceptable addresses we can assign with this mask. Ideally it would have fields for DNS name of the device and a physical location. It could run under DOS, Windows, OS/2, Unix or MVS, as we have all these accessible. The IBM rep we had on site seemed to think this type of thing must exist someone. Thanks. Bleys ========================================================================== = Bleys Ahrens Chicago, IL = = VPNET/Public Access Usenet = = Information gains value when shared... [email protected] = ==========================================================================
-----------[000243][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 1993 03:52:27 GMT From: [email protected] (Sudheer Dharanikota) To: comp.protocols.tcp-ip Subject: Ip Routing Entry...
Hai, This is meant for those who are familiar with ip source code. I am trying to add a new filed in IRE entry. This field helps me in maintaining a private linked list. Could somebody guess what could make the system crash :-< if this field is touched in "ire_delete" and "ire_add" routines. sudheer. e-mail: [email protected]
-----------[000244][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 93 05:17:17 GMT From: [email protected] (Marco S Hyman) To: comp.protocols.tcp-ip Subject: Split Subnet question
Hi,
I've got the following configuration
Net1 - router1 - Net2 - router2 - Net3
|
+ Net4
|
+ Net5
Net1 is a class C network with only 4 hosts on it.
Net2 is a class C network with about 70% of the addresses assigned.
Net3, 4, and 5 are very small - half a dozen hosts each.
What I'd like to do is make Net1, Net3, 4, and 5 subnets of the same
class C address. The problems is that router1 and router2 faithfully
implement RFC 1009 (Gateway requirements) and refuse to route from
Net1 to Net3 because "The distinction of between the subnets of such
a subnetted network must not be visable outside that network."
Is there any way of doing this shy of moving router2 to Net1?
Thanks,
// marc
--
// primary: [email protected] pacbell!dumbcat!marc
// secondary: [email protected] uunet!aria!marc
-----------[000245][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 1993 06:35:54 GMT From: [email protected] (Tony Li) To: comp.protocols.tcp-ip Subject: Re: Split Subnet question
In article <[email protected]> [email protected]
(Marco S Hyman) writes:
I've got the following configuration
Net1 - router1 - Net2 - router2 - Net3
|
+ Net4
|
+ Net5
Net1 is a class C network with only 4 hosts on it.
Net2 is a class C network with about 70% of the addresses assigned.
Net3, 4, and 5 are very small - half a dozen hosts each.
What I'd like to do is make Net1, Net3, 4, and 5 subnets of the same
class C address. The problems is that router1 and router2 faithfully
implement RFC 1009 (Gateway requirements) and refuse to route from
Net1 to Net3 because "The distinction of between the subnets of such
a subnetted network must not be visable outside that network."
Is there any way of doing this shy of moving router2 to Net1?
Yes, but you need to update your router software and run a routing protocol
that supports discontiguous subnets. Your alternatives are currently:
OSPF, Integrated ISIS, and RIPv2.
Tony
-----------[000246][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 93 13:52:24 MDT From: [email protected] (869883 Desai Rutvij Chandrahas) To: comp.protocols.tcp-ip Subject: How to convert The IP addresses
hi, Can any one tell me how can I convert the IP address e.g. 129.123.4.50 to a name string e.g. mendon.declab.usu.edu and vice versa. note : I am looking for the system call that takes either IP address(32 bit) or the dotted decimal address and gives the char string. On my system gethostbyaddr() is returning NULL if the entry is not found in /etc/hosts file. So I am looking for a system call other than gethostbyaddr() to do this. Send me a mail directly or reply on net. Thanks rutvij
-----------[000247][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Oct 1993 15:13:42 From: [email protected] (Edwin Chow) To: comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc Subject: Internet Service Providers in LA area
Does anyone know of names/numbers of Internet service providers in the
Los Angeles area?
If so please mail me at [email protected]
Thanks,
Ed
--
,,, ,,,
(o o) (o o)
______________oOO__(_)__OOo______________________oOO__(_)__OOo______________
Edwin Chow
FTP Software Inc., West Coast Office Internet: [email protected]
785 Market Street, 12th Floor Phone: 415-543-9001
San Francisco, CA 94103 Fax: 415-543-9002
____________________________________________________________________________
(__) (__) (__) (__)
-----------[000248][next][prev][last][first]---------------------------------------------------- Date: 14 Oct 93 20:38:44 +0930 From: [email protected] To: comp.protocols.tcp-ip Subject: Timed, NTP, XNTP ?? The low-down !
Howdy all, I have a few suns and a load of smaller devices that all support rfc-868? that I'd like to have time sych'd across the net. With all the discussion about timed, ntp, xntp etc, Ive been trying to find something to run to keep everything within a 'reasonable tolerance' :-), like within a minute or two would be just fine. Is there an archive site somewhere I can zip off a copy of something straight- forward to achieve this. I assume this means timed, but Ive never looked into this area much. The destination systems are sol 1.1 (os 4.1.3) on ss2's and 10's. I cant find anything cept rdate on the std dist. Any help would be appreciated. (pref something _stable_ if poss) Rob Mayfield Snr Tech Analyst Australian Submarine Corporation Pty Ltd.
-----------[000249][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Oct 1993 18:14:22 From: [email protected] (Frances K. Selkirk) To: comp.protocols.tcp-ip Subject: Re: Can FTP's PC/TCP coexist with MS Win. for WG?
In article <[email protected]> [email protected] (Ian Leveson) writes: > I've just tried installing Microsoft's Windows for Workgroups on a PC which > already has access to a unix server via FTP PC/TCP's NFS utilities. Has > anyone managed to retain access to the TCP/IP network at the same time as > connecting the PC to others via Windows for Workgroups? If so, how? I > suspect that an appropriate network.inf and oemsetup.inf file would help do > the trick: are such files available? Currently, you can not use our Windows network driver as a secondary network driver. The only feature this will prevent you from using is transparent network printing from Windows applications. Pctcpnet NFS drives will be available from our network icon, but not from File Manager. Other than these limitations, the two packages will work simultaneously. There are two ways to get PC/TCP 2.2 working with WfW - they can share an NDIS driver and run side by side, or WfW can run over our NetBIOS. For the latter configuration, you will need a 2.22 patch for NetBIOS. This is free on request to licensed 2.2 users. Send to [email protected] regards, -- Frances K. Selkirk [email protected] FTP Software, Inc. Technical Support (800) 382-4FTP --------------------------------------------------------------------
-----------[000250][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 1993 12:05:43 +0100 From: [email protected] (Mike Hoffmann) To: comp.protocols.tcp-ip Subject: Simple code example for net-daemon under inetd control needed
Hello! I'm a newbie to network programming and would like to ask if someone could provide me with pointers or sources for a simple example of a server-process that is started under inetd control. Most books I have here only provide theoretical assistance and the sources I looked into (like ftpd) are a bit deterring as start-off point. Thanks in advance for any help you can give! Cheers Mike -- Mike Hoffmann - Internet Administrator, Siemens-Nixdorf AG, SNI SU AP 1123 INTERNET: [email protected] We don't know where M[ars] O[bserver] is, if it's listening, or if it's capable of replying. It might not even be transmitting at the expected frequency... Sounds like a job for SETI. ([email protected])
-----------[000251][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 1993 17:54:00 GMT From: [email protected] (Mark Fullmer) To: comp.protocols.tcp-ip Subject: Re: IP Addressing Program/Database
In article <[email protected]> [email protected] (Bleys Ahrens) writes: >We are looking for a shareware or public domain program we can FTP from >somewhere that will assist us with address assignments for a large >internet created from a class B address. > >We would like to be able to plug in our class B address 167.11X >and a default mask of 255.255.255.192 and have the program generate >a flat file or database file with all the acceptable addresses >we can assign with this mask. Ideally it would have fields for >DNS name of the device and a physical location. I use a combination of RCS, m4, and Perl to do this. RCS so that multiple people can edit the database file and mistakes can be easly backed out. Perl to do sanity checking -- eg check for duplicate ip addresses, hostnames, ethernet addresses, etc. m4 just to avoid clutter -- most machines have the same nameserver, timeserver, etc. Perl scripts also generate a bootptab file, readable reports, and some other things. The scripts are really short, if you want I'll stick them up for anonymous ftp. -- mark [email protected]
-----------[000252][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Oct 1993 17:55:52 GMT From: [email protected] (Piercarlo Grandi) To: comp.protocols.tcp-ip Subject: Re: Routing with SLIP
>>> On Thu, 14 Oct 1993 17:53:25 GMT, [email protected] (Rennie Allen) said: In <[email protected]> [email protected] (Brendan Forsyth) writes: Forsyth> [ ... I am gatewaying at the IP level between an unregistered Forsyth> class C network and the internet using a SLIP connection, and I Forsyth> am having problems. ... ] Rennie> The issue you originally raised has nothing to do with routing Rennie> or SLIP connections. Your IP forwarding is working (you saw the Rennie> packets with your protocol analyser), you are sending Rennie> unregistered (and possibly conflicting addresses) out on the Rennie> Internet. This is naughty. It's not just naughty: if your internet access point provider catches you gatewaying at the IP level between an unregistered network anddd the internet they might well (and should!) terminate your connection with great prejudice. It is a condition of the use of the internet at all levels that all IP addresses be registered and therefore unique. Forsyth> Getting a registered number for over 50 nodes and then Forsyth> reconfiguring each is not a feasible solution. If you think getting a registered C class address and renumbering 50 machines is unfeasible, too bad for you (and your organization). You will have to choose one of the following: * stop gatewaying at the IP level between your unregistered network and the internet. * have your SLIP connection terminated by your access point provider as soon as they catch you. * setup your gateway machine as an application level gateway (a so called firewall), where local users log into it and then from it use internet services. I am afraid that there are the _only_ really feasible choices.
-----------[000253][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 93 19:02:20 GMT From: [email protected] (Douglas Luce) To: comp.protocols.tcp-ip Subject: Re: Duplicate IP Numbers
Dewey Paciaffi ([email protected]) wrote: : We have an environment mix of IBM workstations/servers and PCs, : in a wide area Internet. Recently we've seen an increase of PCs running : TCP/IP. Along with this increase has come an alarming number of : duplicate IP addresses being configured into the PCs. The PCs hang : until the situation is cleared up, of course. We are also able to : make workstations and servers hang using PCs. Some people here are : understandably distressed about this. My question is how are others : in this type environment dealing with this issue, be it malicious or : innocuous in intent. We've not implemented a plan here at Duquesne, but here's what I had in mind: We have nearly 20 buildings on campus, each with their own Ethernet backbone. Each of these building have been assigned a subnet, and each has their own port on an IP router. Just doing this will help a bit, since for duplicate IP addresses to be a problem, they both have to occur within the same building. If someone chooses an arbitrary IP number, they won't affect anyone outside the building, and if they don't choose it within the building subnet, they really won't harm anyone at all. Of course, this doesn't get the machine working. It's likely that a person may try several different numbers until one works (one that's in the building subnet). Part of this is grounded in policy: how do people get their networking software? How do they set it up? The plan here is to distribute TCP/IP disks from our computer store. People who want to get on the network will call us or the store up, and we'll get them the proper disks. When they start up from these disks, the first thing that happens is one of: 1) An ARP request is put out, and an ARP server on the ethernet will give out addresses on a dynamic basis, 2) the user will be queried as to his/her location on campus, and a IP address from a small block (2-3) of special configuration IP addresses are chosen. Once a PC has it's temporary IP number, a central server is contacted. A dialogue ensues between the PC and the server, and the user is asked the standard info. This info is put into a form and shipped to an administrator, and an IP address is automatically allocated and given to the PC. Immediately, the PC is up and working with a properly allocated IP address. The info is checked by hand, and the DNS records updated to give a proper hostname, and the info files in the proper place. Of course, if someone gives bogus information, they shouldn't get that IP address. I'm not too sure what to do in this case, but perhaps leave that IP address alone until we locate the person who gave us the bad info and set them straight. How are things done at your site with respect to getting people up on the network? Or is this a malicious problem you're dealing with? Doug Luce Duquesne University CCIT
-----------[000254][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Oct 93 19:37:57 GMT From: [email protected] (Tin Li, Century Computing, ITB) To: comp.protocols.tcp-ip Subject: winsock, pcnfs, and pcnfs toolkit
Our software are currently using pcnfs 4.0 and the library tklibw.lib that come with pcnfs toolkit 4.0 We are in the process of moving to pcnfs 5.0 and changing our application to use winsock. The question is do I still need the pcnfs toolkit since pcnfs come with a winsock dll and the required header files? Have anyone tried the winsock dll in pcnfs? Any pointers will be appreciated. Thanks. Tin Li National Library of Medicine National Institute of Health Bethesda, MD [email protected]
-----------[000255][next][prev][last][first]---------------------------------------------------- Date: 15 Oct 1993 21:54:34 GMT From: [email protected] (Barry Margolin) To: comp.protocols.tcp-ip Subject: Re: Simple code example for net-daemon under inetd control needed
In article <[email protected]> [email protected] (Mike Hoffmann) writes:
>I'm a newbie to network programming and would like to ask if someone
>could provide me with pointers or sources for a simple example
>of a server-process that is started under inetd control.
>
>Most books I have here only provide theoretical assistance and the sources
>I looked into (like ftpd) are a bit deterring as start-off point.
Inetd is described in section 6.16 of "Unix Network Programming" by W.
Richard Stevens.
Basically, inetd automatically does the bind(), listen(), and accept() for
you, and then runs the server program in a child process. When your server
is started, the accepted socket is connected to fd's 0, 1, and 2 (stdin,
stdout, and stderr). So if you have books on writing non-inetd servers,
just ignore the stuff about the above system calls, and look at the parts
of the examples after the socket has been accepted.
--
Barry Margolin
System Manager, Thinking Machines Corp.
[email protected] {uunet,harvard}!think!barmar
-----------[000256][next][prev][last][first]---------------------------------------------------- Date: Fri, 15 Oct 1993 22:49:22 GMT From: [email protected] (walter.h.goodman) To: comp.protocols.tcp-ip,comp.unix.wizards,comp.unix.admin,comp.unix.sys5.r4 Subject: Lachman TCP/IP over STARlan10...PLS HELP.
People of the Net, I have a 486 EISA machine running SVR4.0.3 (Consensys) with STARlan Lan Manager and a STARlan10 network card. I would like to configure TCP/IP over this card. Unfortunately the TCP/IP that I have is the version created by Lachman Associates, Incorporated (LAI) not the WINTCP that AT&T sells. I am having some difficulty configuring this TCP/IP over my STARlan10 NAU. Does anyone out there have any experience configuring the Lachman brand of TCP/IP over a STARlan10 card? Can it be done? I have my system up enough that I can ping myself, but no other hosts on our net. (doesn't do me much good to be able to rlogin to myself ;-/) Any assistance will be much appreciated. Walter H. Goodman AT&T IMS, Kansas City [email protected]
-----------[000257][next][prev][last][first]---------------------------------------------------- Date: Sat, 16 Oct 1993 05:01:41 GMT From: [email protected] (Vance Shipley) To: comp.protocols.tcp-ip Subject: Interface Based Routing
I have been experimenting with the KA9Q routing software for use in our local MAN project (KWNet). I have been trying to take advantage of the software's ability to do interface based routing which allows me to use the C Class IP network space we have been allocated very effectively. We currently have several routers which each have only one IP number. Each machine with a route to one of these routers uses the same IP number in it's routing tables. This has so far worked out very well. Hosts attaching to a router are allocated one of KWNet's numbers if they have no network of their own. If they do we encourage them to use one of their own numbers for the interface. With this arrangement we have been able to avoid subnetting the C Class and only use up a number when we add a host which does not have it's own IP network. I am very happy with this arrangement and am favouring using a KA9Q based package for this reason alone. Despite this a number of our group are very suspicious of this capability describing it as "strange" or even "illegal". I have yet to see anything which proves that this method of "interface based routing" breaks any standards, RFCs, etc. So I am soliciting comments. Is "interface based routing" "illegal"? Is it undesirable? Or is it, as I feel, what should have been done all along? -- Vance Shipley, [email protected]
-----------[000258][next][prev][last][first]---------------------------------------------------- Date: Sat, 16 Oct 1993 11:43:10 GMT From: [email protected] (Jan Engvald LDC) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: pdclk207.zip - Network tester & sets PC clock from LAN t-serv
I have uploaded to the SimTel Software Repository (available by anonymous
ftp from the primary mirror site OAK.Oakland.Edu and its mirrors):
pub/msdos/pktdrvr/
pdclk207.zip Network tester & sets PC clock from LAN t-serv
PDCLKSET sets the time and date of the PC clock using a TIME server.
It has daylight saveing (summer time) algorithms for most of the world.
It can use BOOTP to get IP number and other info. PDCLKSET talks to the
network card via a packet driver (using ODIPKT or DIS_PKT you can run it
over ODI or NDIS too).
PDCLKSET can assign the proper normal or summer time timezone name to
an environment variable (TZ is used by most systems).
There is also a very powerful built in ping/echo client and server
giving important statistics on delay, load and packet loss. It can even
load a network to the full Ethernet bandwidth. It can be used to stress
software and hardware components such as driver routines, routers,
bridges, repeaters, Ethernet cards and transceivers.
The PDTBUILD program, which is included in the ZIP package, looks at all
ARP broadcasts and generates hardware address tables with all the IP
hosts on this (sub)net. It detects IP and hardware address duplication.
And still, PDCLKSET is so small (14 KB) you can use it even on diskette-
only PCs.
Version 2.07 of the PDCLKSET package has the following new features
compared to the 1.52 version, making it still better for network load
testing and detecting beginning component failures:
- On a VERY loaded network the ping server could run out of buffers
(indicated by a number between packets received and diff). The code
has now been rewritten to use far addresses for buffers and the buffer
pool is now 300+ full size buffers as compared to 27 on 1.x versions.
Using a good packet driver (e g the coming/new smc_wd ver 11.x) and with
a server that is faster than the client, there should be zero packet loss
due to software; so one can clearly see how the hardware performs.
- During pinging, packet loss is computed differently so packets in
transit are not counted as loss. This gives a more true and stable display.
- Code optimizations has given a throughput increase of about 50 - 70 %,
a 20 MHz 386 can load the net to 9.9 Mb/s using full length packets and a
33 MHz 386 can load to 1/3 Ethernet capacity using minimum length packets.
- The interval parameter may have a decimal point and one decimal digit
(more natural than the flag=32 mechanism in 1.x versions).
- A new min-size parameter can override the 34 bytes default minimum size
when doing packet size sweep.
- Table building now looks at IP broadcasts in addition to ARP broadcasts.
- Added special handling for true SLIP and Token Ring (untested,
no source routing).
- Flag=4096 enables IP sizes up to 4082 (for Token Ring, but also
requires changes to the IBMTOKEN packet driver, unless true TR works).
- Echo interval algorithm changed to be more accurate and CPU speed
independent.
- Some minor bugs fixed (and probably new ones introduced).
There is no functional change regarding setting the PC clock from the net.
Jan Engvald, Lund University Computing Center
________________________________________________________________________
Address: Box 783 E-mail: [email protected]
S-220 07 LUND Earn/Bitnet: [email protected]
SWEDEN Span/Hepnet: Sweden::Gemini::xjeldc
Office: Soelvegatan 18 VAXPSI: psi%2403732202020::xjeldc
Telephone: +46 46 107458 X.400: S=Engvald/G=Jan/O=ldc/
Telefax: +46 46 138225 PRMD=lu/ADMD=sunet/C=se
Telex: 33533 LUNIVER S
_____________________________________________________________________________
Jan Engvald, Lund University Computing Center, Box 783, S-220 07 LUND, Sweden
Telephone: +46 46 107458 Telefax: +46 46 138225 Telex: 33533 LUNIVER S
E-mail: [email protected]
X.400: G=Jan/S=Engvald/O=ldc/PRMD=lu/ADMD=sunet/C=se
-----------[000259][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 1993 02:42:02 -0700 From: [email protected] (Samuel Lam) To: comp.protocols.tcp-ip Subject: Re: Registering IP Addresses
In article <[email protected]>, Dan Lacey <[email protected]> wrote: >I would like to obtain my very range of IP addresses. How do I get them? >I assume the NIC, but what is the post office or Email address I use to >get an application? You could get the application form via anonymous FTP from ftp.rs.internic.net:netinfo/internet-number-template.txt , or via e-mail from <[email protected]>, or by phoning the NIC at 800-444-4345 or 703-742-4777. ...Sam -- <[email protected]> -- Connectivity Technology Inc. "NetNews on CD's" product information: <[email protected]>
-----------[000260][next][prev][last][first]---------------------------------------------------- Date: Sat, 16 Oct 1993 15:18:35 GMT From: [email protected] (Peter Rindfuss) To: comp.protocols.tcp-ip Subject: SLIP and BOOTP
I'm using cslip-2.6 as a slip server on our Sun Sparc 2. I would like to configure the system in such a way that the bootpd daemon can respond to bootp requests from the slip line. Bootpd gets the requests from the slip line, but it can't answer them because there is no hardware address it can reply to. Does anyone have an idea how this could be established?
-----------[000261][next][prev][last][first]---------------------------------------------------- Date: Sat, 16 Oct 1993 15:41:01 GMT From: [email protected] (Peter Karrer) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: IP address 224.0.0.5 ?
[email protected] (Art Berggreen) writes: >In article <[email protected]> [email protected] (Peter Karrer) writes: >>It seems that our Cisco routers talk to each other sending broadcasts with >>a destination IP address of 224.0.0.5 (protocol 89). What is this? >OSPF (probably router Hellos) IP multicast. >>[...] >These should only be going out on the MAC multicast of 1-0-5E-0-0-5. >If they are being sent to the MAC broadcast, check with Cisco. If they >are using the the correct multicast, you host software shouldn't see >them, so complain to the host software vendor. >>[...] Here's a KA9Q trace: Sat Oct 16 15:42:15 1993 - tok recv: Ether: len 82 40:00:00:76:15:00->ff:ff:ff:ff:ff:ff type IP IP: len 68 193.5.187.33->224.0.0.5 ihl 20 ttl 1 tos 192 prot 89 .... If I understand you correctly, this should be addressed to 01:00:5e:00:00:05 and not to ff:ff:ff:ff:ff:ff?! This might be a configuration error on our side; we have just recently switched from source routing bridges to Cisco routers. (BTW, "we" != ETHZ.) Or perhaps the fact that it's a Token-Ring network makes the difference... (Does Token-Ring support the concept of multicast?) -- Peter Karrer [email protected]
-----------[000262][next][prev][last][first]---------------------------------------------------- Date: 16 Oct 1993 20:34:28 GMT From: [email protected] (Kevin Lund) To: comp.protocols.tcp-ip Subject: Help needed with routing table interpretation
I'm trying to run PPP from a Sparc LX to a mac; the PPP link comes up,
but no network traffic comes across it...so I'm looking at the routing
tables, and here's what I get:
[much deleted]
138.23.106.0 138.23.146.1 UG 0 0
198.102.62.0 138.23.146.3 UG 0 0
134.24.0.0 138.23.146.3 UG 0 0
138.23.146.0 138.23.146.195 U 3 4683 le0 <--*
224.0.0.0 138.23.146.195 U 3 0 le0
138.23.146.111 138.23.146.195 UH 2 0 dp0 <--*
default 138.23.146.3 UG 0 0
Now, the machine I'm trying to get packets to is 138.23.146.111 (the
one on the other side of the dp0 interface). However, there is an
entry, earlier, for all of 138.23.146.*, which specifies interface
le0. My question is, when there's a packet destined for 138.23.146.111,
will the routing table get searched in the order given here (as dumped
by netstat), thus sending the packet out the wrong interface? If
so, how can I reorder the table?
If not, anybody have PPP going between a Solaris machine and a mac?
Thanks,
Kevin Lund ([email protected])
-----------[000263][next][prev][last][first]---------------------------------------------------- Date: Sat, 16 Oct 1993 22:14:12 GMT From: [email protected] (Art Berggreen) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Re: IP address 224.0.0.5 ?
In article <[email protected]> [email protected] (Peter Karrer) writes: >[email protected] (Art Berggreen) writes: >>These should only be going out on the MAC multicast of 1-0-5E-0-0-5. >>If they are being sent to the MAC broadcast, check with Cisco. If they >>are using the the correct multicast, you host software shouldn't see >>them, so complain to the host software vendor. >>>[...] > >Here's a KA9Q trace: > >Sat Oct 16 15:42:15 1993 - tok recv: >Ether: len 82 40:00:00:76:15:00->ff:ff:ff:ff:ff:ff type IP >IP: len 68 193.5.187.33->224.0.0.5 ihl 20 ttl 1 tos 192 prot 89 > .... > >If I understand you correctly, this should be addressed to 01:00:5e:00:00:05 >and not to ff:ff:ff:ff:ff:ff?! > >This might be a configuration error on our side; we have just recently >switched from source routing bridges to Cisco routers. (BTW, "we" != ETHZ.) >Or perhaps the fact that it's a Token-Ring network makes the difference... >(Does Token-Ring support the concept of multicast?) Ah, Token Ring. I had assumed Ethernet. Token does have the concept of multicast, but usually "functional address" (a subset of multicast) is used for these types of functions. The above multicast on TR would be bit reversed and read as 80:00:7a:00:00:a0. Off the top of my head, I don't remember if IP multicast has a defined TR functional address, so I can believe that it might show up using the ff:ff:ff:ff:ff:ff broadcast. At any rate, your host should be ignoring these. Art
-----------[000264][next][prev][last][first]---------------------------------------------------- Date: Sun, 17 Oct 1993 12:27:14 GMT From: [email protected] (Samson Chen) To: comp.protocols.tcp-ip Subject: INETD fork procedure!?
Hi,all, Sorry, it's me again... I'd like to know whether the inetd fork procedure below is correct or not! inetd find a connection | inetd check the port | inetd accept that connection | inetd dup the connection to stdin/out | inetd fork | inetd transfer control to another program charge for that port I don't know if this question is a dumb one. Anyway, thank you for reading it. /\/\/\/\/\/\/\/\/\/\/\/\/\/\ Samson Chen at C.H.P.I., Hsin-Chu, Taiwan. e-mail: [email protected]
-----------[000265][next][prev][last][first]---------------------------------------------------- Date: 17 Oct 1993 18:29:20 +0100 From: [email protected] (Christophe Wolfhugel) To: comp.protocols.tcp-ip Subject: Socket stuck as "CLOSING"
Some really bad TCP implementations (like in AIX 3.2) won't close sockets if they don't get the final ACK or some of the last waited datagram, which offten happens with crashing machines. Those bad implementations keep the sockets definitely in a bad shape: Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 134.214.100.25.70 152.3.102.1.4077 TIME_WAIT tcp 0 126 134.214.100.25.20 128.186.41.102.55969 CLOSING tcp 0 16384 134.214.100.25.70 138.253.241.52.2912 LAST_ACK [hundreds of lines ommitted] Desperate from getting the vendors fix their software, do I have a way to send to "shit" into the TCP layer to have those sockets closed. The ICMP unreachable does not work (even for normally active sockets) as IBM decided not to follow them. Could sending RST, FIN or I don't know what help finishing the handshaking. Another issue is that I have no idea on the expected values for Ack, Seq, ... Fortunately AIX's kernel does have raw IP sockets which allow the user to specify the complete IP header (and fake easily the source address). -- vive les calories
-----------[000266][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Oct 1993 01:25:41 GMT From: [email protected] (Simon Rumble (Shermozle)) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp.ip,comp.protocols.ppp,comp.protocols.pcnet,apana.general Subject: Re: Looking for alternative to pc-route...
Seems like on Wed, 13 Oct 1993 15:03:35 GMT Christoph Weber-Fahr [KIT] said: : >BTW why not take one of the free Unix versions ? Linux ? NetBSD (or what : >they call it this week) ? : That question seems to remain unanswered. Well the problem is, we're talking about Toasternet here. We want to repurpose old, obsolete and, importantly, cheap techology such as XTs, 286 machines etc. PCRoute is good at this. You really shouldn't need that much oompf for a maximum of 4 serial ports (although the I/O could be a problem). -- //___///////////////////////////////////////////////////////////////////////// /|___ "What's the point of a revolution without general copulation?"/ / ___| H E R M [email protected] / //////////////////////////////////////////////////////////////////////////////
-----------[000267][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Oct 1993 01:29:02 GMT From: [email protected] (Steve Kotsopoulos) To: comp.protocols.tcp-ip Subject: Re: problems with large packets on UDP
In article <[email protected]>, Tony Li <[email protected]> wrote: >In article <[email protected]> [email protected] (Matthias >Urlichs) writes: > > If I were you, I wouldn't send one large UDP packet and let the IP > layer split it -- split it yourself, say to 8k or so (same as NFS...). > That way you receive bits and pieces of your picture, enabling you to > keep old picture fragments around in case a packet gets lost. If that > happens to your big UDP packet, the whole picture gets tossed when the > kernel times out (which can be a few seconds). > >In fact, if you can fragment your data yourself, it's much better to send >path MTU sized datagrams. NFS is not a particularly good model, as those >8k packets do get fragmented. Any loss of a single fragment implies >retransmission of all fragments for that packet. Why is it better to fragment your data into MTU-sized datagrams? Is this always true, or only if you are retransmitting a lot? How much better is it? Do you have any references I can look up? I have heard people say this before, but my experimentation gives me the opposite answer. I am working on a project where we want to send very large files to many hosts on a LAN at once. In order to simplify the one-to-many communication, we use multicast (if available) and broadcast; thus, we must use UDP. When we benchmarked our protocol for various packet sizes, we found that the larger the packet size, the better our throughput. We figured this was due to minimizing system calls; we just hand an 8K packet to the kernel, and let it take care of fragmenting it. (of course, we can't use 8K packets when broadcasting) By the way, we only end up retransmitting < 5% of all packets. Our conclusion: system calls are expensive, so minimize them. -- Steve Kotsopoulos P.Eng. mail: [email protected] Systems Analyst bitnet: [email protected] Engineering Computing Facility uucp: uunet!utai!ecf!steve University of Toronto phone: (416) 978-5898
-----------[000268][next][prev][last][first]---------------------------------------------------- Date: Mon, 18 Oct 1993 02:02:35 GMT From: [email protected] (Elena Leong) To: comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains Subject: Location of gated
Hi, the subject says it all, I need an ftp source for gated, preferably in Australia Please mail me a reply if possible, because I dont read news that often. Thanks, Elena.
-----------[000269][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 1993 02:51:17 GMT From: [email protected] (Sageev George) To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip,comp.sys.novell Subject: SLIP routing software that can login w/ password ?
We are getting a SLIP connection to get our network on the Internet. We had planned to use Wollongong's WIN/Route (very old package we had lying around) to provide us with the SLIP routing (i.e. a PC running this, with our thin-net Ethernet card and SLIP modem connections, routing betwixt the two). However, after reading the WIN/Route docs and talking to our SLIP provider, I don't thik this will work because the SLIP router must login to the providers machine with a userid and password. Thus: I need some type of software that I can run (on a PC pref. but on our Sun if necessary) that can dial up to our SLIP account, log in and do the SLIP nasty. If anyone knows of any such software, PD or commercial (obviously PD is preferred :), please let me know. Thanks for any info.
-----------[000270][next][prev][last][first]---------------------------------------------------- Date: 18 Oct 1993 12:07:41 GMT From: [email protected] (Gary J Palmer C.S.3) To: comp.protocols.tcp-ip Subject: gethostbyname()
I am writing a program that looks up a host (either by gethostbyname() or gethostbyaddr()), and I want to find out all the aliases for the host. But using those two system calls, I only get *one* alias for the host, and only if I specify the alias as the host to find. Using the gethostby*() system calls is it possible to find all the aliases? I am running Sun4.1.1 on a Sparc ELC, with DNS set up in /etc/resolv.conf. Thanks Gary -- JANET : [email protected] Other Nets : gpalmer%[email protected] plus one of :- BITNET: UKACRL UUCP: ukc.uucp Internet: nsfnet-relay.ac.uk #include <std.disclaimer> | Ah... f**k ... NT has been released :-(
-----------[000271][next][prev][last][first]---------------------------------------------------- Date: Sat, 23 Oct 1993 14:07:21 GMT From: [email protected] (Pete A. Zaitcev) To: comp.windows.x.motif,comp.protocols.tcp-ip Subject: Re: HELP -- Chat - like program
In <[email protected]> [email protected] (frank james lagattuta) writes: > I am trying to create a program which enalbles a networked user to talk to >another networked user through headsets and microphones via the network >connection. I am doing the same, but VER-RY slowly. I am very busy on the main work. This theme becomes hot! A couple of months there was a discussion in the comp.sys.sun.misc under the subject "audio talk between the sparcsta- tions". This theme is also unfolding in the our local group relcom.fido.ru.unix. I think that we will face the compatibility problem soon. Someone should establish the standard about the bidirectional transmission of sound data over the IP. The RFC-1256 seems for me not to be suitable. It's targeted on the broadcast transmission. I use now the protocol from the John Walker's NetFone. It's too unsecure and consume the extra bandwidth because of uLaw format being used in it. Can somebody suggest anythig better? Yes, I can say "ADPCM", too :-) But the complete protocol must include signaling capabilities and other important things. Please send any responces to me. I will post edited summary. Pete
-----------[000272][next][prev][last][first]---------------------------------------------------- Date: Thu, 28 Oct 1993 02:05:00 GMT From: [email protected] (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Newbie needs a dummy.net IP address
In article <[email protected]> [email protected] (Gary Heston) writes: >... >>I'd like to set up an internal network (never seen outside the corporation) >>and use a dummy, Class B address. Then I can reserve my precious NIC-legal >>Class C addresses for hosts that actually connect to the Internet. > >Sorry, it's not allowed. There's no way under current network software >to make this work, unless you keep it physically isolated as well--as >in passing email to and from it via a uucp link. Otherwise, you'll never >get it to work reliably. > >>I asked Hostmaster at Internic if there was a "test" or "experimental" IP >>address, guaranteed never to be issued, and learned that there is none. Hostmaster at Internic was wrong or was misunderstood. Check 192.0.2 in Assigned Numbers. 192.0.2 was long ago designated for exactly such uses by Jon Postel in response to my request. >>How do I randomly pick a dummy Class B address for internal use only that >>won't conflict with real-world addresses? > >There *aren't* any dummy class B addresses! Nets 89 and 10 would serve well enough as dummy class B's for a long time, because of different but similar histories. Furthermore, given the officially sanctioned dummy test class C, 192.0.2, you can build a pair of MX forwarders that would pass mail between the Internet and an internal hidden currently actively used class B (e.g. 16), and not have to use UUCP. Vernon Schryver [email protected]
-----------[000273][next][prev][last][first]---------------------------------------------------- Date: 28 Oct 1993 16:33:16 -0400 From: [email protected] (Martin Walker) To: comp.protocols.tcp-ip Subject: Re: FTP's PC/TCP MS Win. Printing woes
[email protected] (Douglas Luce) writes: >Okay, I've got a Postscript printer on my NeXT, and the latest and greatest >PC/TCP from FTP software. I want to print to this printer from the PC in >my office under MS Windows. > >So I install it. Straightfoward; it works with my Ethernet card and all, >allows me to point a queue at an lpd on my NeXT. Everything works; NFS >mounts great, I can FTP/Telnet. Fine. I print; data gets to the printer, >but it's raw Postscript code. At the top of the job is a mysterious >line: \004!%PS-Adobe >Wow, I think to myself, I know exactly what this is: the Ctrl-D hack in >Windows (I assume to attempt to flush any pending job from the printer). >Even better, I know the solution: find the part in my WIN.INI that says >[Postscript, LPT1] and put a CtrlD=0 in there. It even reiterates this >in the MS-Win readme file. Cool enough. >So I do it. To no effect. FTP's tech support (on preliminary investigation) >has no palpable clue. >Am I missing something? Has anyone else been in this bind, and sounded out >the brain damage? >Thanks, >Doug Luce >Duquesne University CCIT i do something similar on sco boxes. the trick is to tell the printer interface that all jobs from the pc are "graphics", in other words this is a binary file which should be dumped to the printer port as is without adding anything on the from er backup. most unix interfaces will try to set up the printer before sending the presumably text job. you may have to send the pc print jobs to an alias which is really lp -og printer not sure how the next deals with this.
-----------[000274][next][prev][last][first]---------------------------------------------------- Date: 29 Oct 93 16:27:25 GMT From: [email protected] (James Baker) To: comp.os.ms-windows.setup,comp.os.ms-windows.misc,comp.protocols.tcp-ip Subject: Re: Windows for Workgroups over TCP/IP
You can get it from Microsoft for $49.00.
-----------[000275][next][prev][last][first]---------------------------------------------------- Date: Fri, 29 Oct 1993 20:48:59 GMT From: [email protected] (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: ICMP redirect security?
In article <[email protected]> [email protected] (Mark Evans) writes: >... >: Gateways (routers) don't listen to ICMP redirects exactly for this (and >: other) reasons. > >A machine sould check the source address against its routing tables. >So that it only accepts redirects from a gateway it is using, many machines >appear not to bother checking, thus can be spoofed. No one who cares about security puts much faith the IP source address of an ICMP packet or any other IP packet. If you can forge the rest of the contents of an ICMP packet, you obviously can forge the source address and, if necessary, some source routing. Even checking the MAC source address is no protection against evil on the local wire, and depending on the gateway and what it does about source routing and whether the target notices source routes, no protection against remote bad guys. Vernon Schryver [email protected]
-----------[000276][next][prev][last][first]---------------------------------------------------- Date: Sun, 31 Oct 1993 02:49:15 GMT From: [email protected] (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: ping's maximum packet size
In article <[email protected]> [email protected] (Frederick Scott) writes:
>[email protected] (Chris Kostick) writes:
>>
>>On a Sun (SUNOS 4.1.3) I tried
>>
>> $ ping -s afterlife 2048
>> PING afterlife.ncsc.mil: 2048 data bytes
>> sendto: Message too long
> ...
>I don't think the problem is with sendto(). What kind of network are you
>pinging on? An ethernet network has a maximum packet size of 1518 bytes,
>...
The Ethernet (not 802.3) MTU is 1500 bytes of IP (including ICMP) packet.
>Anyway, the point is, I don't think there's any way you can convince SunOS
>to fragment your ping packet on the local network. You're stuck with the
>maximum packet size. ...
Only with some systems.
Other UNIX systems with TCP/IP from 4.3BSD or newer allow ICMP ECHO
Requests and Replies to be fragmented. Besides some systems sold
by hardware vendors, BSDI's BSD386 works:
] PING 192.48.190.8 (192.48.190.8): 5000 data bytes
] 5008 bytes from 192.48.190.8: icmp_seq=0 ttl=255 time=26.102 ms
] 5008 bytes from 192.48.190.8: icmp_seq=1 ttl=255 time=25.211 ms
] 5008 bytes from 192.48.190.8: icmp_seq=2 ttl=255 time=25.127 ms
]
] --- 192.48.190.8 ping statistics ---
] 3 packets transmitted, 3 packets received, 0% packet loss
] round-trip min/avg/max = 25.127/25.470/26.102 ms
Vernon Schryver [email protected]
-----------[000277][next][prev][last][first]---------------------------------------------------- Date: 31 Oct 93 19:51:16 GMT From: [email protected] (Razvan G. Herdea) To: comp.protocols.tcp-ip Subject: ignore
ignore , test
-----------[000278][next][prev][last][first]---------------------------------------------------- Date: 1 Nov 1993 11:36:29 -0800 From: [email protected] (Lon Stowell) To: comp.protocols.tcp-ip,comp.dcom.lans.ethernet,comp.dcom.lans.misc Subject: Re: SUMMARY: Searching for WAN simulator 'black box'
In article <[email protected]> [email protected] (Jim Carroll ) writes:
>
>In summary, there isn't a lot out there to choose from. No recommendation
>at this point.
>
If you really want to simulate the WAN for various international
connections, try the Telecom Analysis Systems units. They have a
competitor with the initials PTT, but I can't recall the full
name.
The TAS-1010 emulates a telco network...complete with delays,
attenuation, echo, phase shift, phase hits, gain hits,
equalization errors, etc. etc. etc. All of these parameters are
under user control.
It is really designed for testing modems, but it can create the
latency and delays of the telco network if that is what you need.
It (and the PTT unit) is a telco channel simulator....with preset
configs for "typical" good, bad, and ugly samples of various phone
lines from various telco's around the world.
The LPCOMM TC-2000, HP-IDACOM, and Wandel & Goltermann DA-30 can
all emulate the protocol but you'd have to know telco effects very
thoroughly and their effect on the link levels to use one of
those.
If you can't find the address of TAS, post on the modem and
telecommunications newsgroups...most modem vendors use the TAS
for designing modems.
-----------[000279][next][prev][last][first]---------------------------------------------------- Date: 1 Nov 93 03:27:40 CDT From: [email protected] To: comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip Subject: Questions for QVTNet 3.93 and 3.94
Hello there, I have the following questions about QVTnet for Windows: 1. In the file qvtnet.ini in the [nntp] section what do you need to put for the posthdr_distrib= option? I guess for USA you put 'usa'. what do you need to put for Interneational? Whatis 'na' stand for? what if you leave this option blank? 2. Is it possible to save the file news.rc to another directory other than c:\qvtnet? 3. Do you need to exclude the frame where the packet driver say wd8003e.com is loaded form the Windows memory using the emmexclude statement? In other words, if wd8003e.com is using the RAM frame cc00-cfff i.e. wd8003e 0x7e 10 0x300 0xcc00 do you need to put the statement emmexclude=cc00-cfff in the [386Ench] section of the system.ini file? 4. What are the new features of QVTNet 3.94? I would appreciate any relevant response. Please E-mail: [email protected]
-----------[000280][next][prev][last][first]---------------------------------------------------- Date: Sun, 31 Oct 1993 23:24:56 GMT From: [email protected] (Vernon Schryver) To: comp.protocols.tcp-ip Subject: Re: Finding hop-counts
In article <[email protected]> [email protected] writes:
>...
>The Berkeley routing table does not keep hop counts. They are irrelevant
>to actual packet routing. Hop counts are relevant only to distance-vector
>routing protocols, such as RIP. Berkeley's routed(8) implements RIP.
>Other routing daemons for BSD-based networking do so as well (e.g. GateD).
>I don't know if there is a way to get them to print their internal tables.
Some workstation vendors ship something derived from the "query"
command associated with the primordial RIP daemon, 4.*BSD routed.
For another example, the query.c found with BSD386 1.0 says things like:
44 bytes from localhost(127.0.0.1):
(af 0) 0 0 0 0 0 0 0, metric 15
(af 0) 30c0 be 0 0 0 0 0, metric 1
I think recent versions of Cisco's code respond to the queries generated
by `query` or `rtquery`.
Vernon Schryver [email protected]
END OF DOCUMENT
| ISSN 1742-948X 01 (Online) | 2005/03/01 | Copyright 2002-2008 securitydigest.org. All rights reserved. |