Date: Mon, 8 Feb 93 04:30:11 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #37
To: tcp-group-digest
TCP-Group Digest Mon, 8 Feb 93 Volume 93 : Issue 37
Today's Topics:
KA9Q NOS and EMS
Multi-Port RSPF (7 msgs)
NOS TEXT
NTP and RDATE
PE1CHL Help
rcs and source (2 msgs)
RDATE questions and comments (3 msgs)
STAT
Verifying have proper CPU for executable
XMODEM for NOS
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Sat, 6 Feb 93 18:18:19 -0800
From: Phil Karn <karn@qualcomm.com>
Subject: KA9Q NOS and EMS
To: Alan Cox <iiitac@pyr.swan.ac.uk>
>Has anyone done any work with allocating local memory in EMS blocks under
>KA9Q, before I start fiddling with it.
>
>ALan
Not that I'm aware of. I suspect this will be difficult, considering NOS's
heavy dependence on dynamic memory allocation and linked lists.
I've heard suggestions of using EMS or XMS to hold the screen scrollback
buffers, but a much easier way to accomplish the same thing is to put the
temp files on a ramdisk.
Phil
------------------------------
Date: Sun, 7 Feb 1993 00:01:01 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: Multi-Port RSPF
To: tcp-group@ucsd.edu
Phil Karn notes,
>Maybe the problem is that you're putting RSPF at the wrong level. The
>problem isn't really with the NOS routing code per se, it's with the
>Internet model itself which says that subnets are fully connected.
>Maybe the right place for RSPF is *below* IP, where it has direct
>access to each physical interface. It could then provide IP with what
>it wants in the first place (a subnet that appears to be fully connected)
>and it could be used to support protocols other than IP.
We can argue forever as to who's at fault, but the fault remains:
The "Internet model" of "subnet" simply doesn't apply to packet
radio, where connectivity is never reliable. That's why RSPF is not
OSPF, RIP, or anything else. It's purpose-built for radio, and
actually doesn't understand "subnets" (in the Internet sense) at all.
Instead of subnets, RSPF considers every host to be a "network", but
creates "node groups" as a way of rolling up information. A subnet is a
form of node group, but an RSPF node group isn't a subnet because it
can't assume perfect connectivity. I introduce this semantic
distinction because when people say "subnet", they indeed expect full
connectivity.
I could create a routing protocol that handles everything else besides
IP, but that would be clumsier for pure IP. I mean, there is "TheNET
and its clone" (I think that's what I call it in the RSPF doc) which is
a pretend-routing subnet. But IP people expect routing to work with IP
addresses. Unfortunately, because of the "subnet" concept, they put
routing on top of the IP layer, which breaks when subnets don't exist.
The real problem as I see it is that the NOS IP interprets node groups
(44.56.0.128/7) as internally-connected subnets. RSPF treats them as
"probably connected", but really needs a way to test them.
I'd rather meet you half way: Put RSPF _in_ the same layer as IP, with
the same access to the lower layers (what OSI calls subnets and what IP
Classic calls Networks, as in AX.25) as IP. And let RSPF build the
routing tables for IP, using no true subnets at all, but using node
groups which just happen to work the same way and make use of the same
code.
The only problem I see with this is that it mimics the OSI RM view, in
which IS-IS lives in Layer 3 and not above it, and some folks are
religiously opposed to doing things the same way as they do. I'm to
practical to get involved in religious warfare. (We have enough hams
already pretending to be non-ham 4N4s.) And maybe it requires a minor
rewrite to the IP_Route module in NOS, to allow RPSF to directly test
routes without destroying contradictory information (other routes to the
same destination) already on the route table. But if we promise to
never call them "subnets", and declare that if RSPF is on, the subnet
mask is always "FF FF FF FF", then we aren't even technically breaking
the IPRM.
fred k1io (still hoping somebody will implement RSPF 2.2)
------------------------------
Date: Sun, 7 Feb 1993 00:16:23 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: Multi-Port RSPF
To: tcp-group@ucsd.edu
Andy Warner asks,
>> The RSPF problem is not restricted to multi-homed hosts, where the host
>> [...]
>> getting permanently locked and such.
>So, the only currently available platform that would want or need
>RSPF can't have it, is that the abridged version ?
It's not _only_ useful on multi-homed hosts. Because radio networks are
never "fully connected" like Ethernets, it's possible for one station to
hear two others who don't hear each other. RSPF allows that kind of
one-channel routing. That part actually works halfway decently in the
existing V2.1 code.
fred k1io
------------------------------
Date: Sun, 7 Feb 1993 1:39:11 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Multi-Port RSPF
To: karn@qualcomm.com, tcp-group@ucsd.edu
I'm not sure I like this new situation where Phil and Fred are starting
to agree on moving RSPF below IP...
RSPF actually doesn't fit into the layering model very well. Network
routing is really at least a Network layer function, and it can be
debated as to whether it should be considered a Transport layer function.
However, a routing protocol is necessarily bound to the Network layer,
in that RSPF becomes non-sensical unless it is used to route IP frames.
Fred captures the underlying problem very well in a few sentences. RSPF
can't test a route with an IP frame unless that route is on the IP routing
table, but it should not put a route on the IP routing table unless it
already know that the route is good. There are several ways to fix this,
none of them even close to easy to code, and some not even easy to describe.
Phil's idea about having RSPF talk directly to interfaces, bypassing IP, is
a coding nightmare. Worse, I can't see any easy way to do this without
assuming RSPF to be running at both ends, and one of the major advantages
of the original design is that only one end of a link must run RSPF. Still
worse, this would force RSPF to be local in scope, abandoning the whole
link-state model of which Fred is justifiably fond.
Another serious problem is that RSPF should be able to establish routes
across any type of interface. Otherwise, two RSPF routers linked by SLIP
or Ethernet would be unable to learn about the routes which the other
acquired by RSPF. I suppose that trult awful kludges could be arranged,
such as using RIP across SLIP or Ethernet to propagate RSPF routes, but
this would be extremely messy.
Ultimately, the only way out is to replicate most of the IP routing code
inside the RSPF code, so that RSPF tests routes using a different table
than then the "real" IP routing code. I have phrased this as "virtualizing
the IP routing table" in the past, and it is a lot of work. Simpler
solutions, such as adding a SunOS-like "DONTROUTE" flag to the IP router
really are not going to do it. A corollary problem is that the RSPF code
must be capable of testing more than one route at a time, and this would
require multiple virtual IP routing tables.
In addition, the layering in the original proposal was not entirely clear,
an issue which Fred and I have discussed previously on many occasions. For
example, Fred strictly requires that the two main types of RSPF information,
the "Router-to-Router Hello" and the "RSPF Update" frames, be sent above IP
directly, effectively making RSPF its own Transport layer protocol. Aside
from the seven-layer model, there really is no functional gain realized by
doing this instead of, say, letting RSPF use a UDP socket, while the penalty
in complexity and size of code is substantial. On the other hand, RSPF uses
conventional ICMP Echo Request messages ("pings") to test routes, which is
the root of its problems, since this makes RSPF dependent upon another
Transport layer protocol for its operation.
Not only is RSPF itself crossing the protocol layers, which is really
inevitable in any routing protocol, but it is intertwined with other things
that cross protocol layers, especially ARP. Because the basic purpose of
ARP is to map a relationship between the Network and Link layers, it is a
particularly awkward place to tie anything into, let alone something as
complicated as RSPF. Of course, RSPF does not depend upon ARP to work, as
long as the other end of the link also runs RSPF; ARP is only used by RSPF
to pick up potential links to routers which are not themselves running
RSPF, since they do not send RRH frames.
Multiport RSPF is not a minor problem. It is an impasse.
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: Sun, 7 Feb 1993 1:55:02 -0500 (EST)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Multi-Port RSPF
To: andyw@aspen.cray.com, tcp-group@ucsd.edu
I think the abridged version is that RSPF does not currently work, and that
this is not going to be easy to fix. I was not suggesting that IP addresses
would be independent of routing, but only that they would not imply routing.
The proper use of RSPF is not to publish every known route to every known
host, but rather to propagate the minimum necessary routing exceptions to
the usual routes. There is no reason to assign IP addresses in a meaningless
order so that there is no relationship to routing, and it is true that this
would be grossly inefficient. However, a host should not be tied down by its
IP address, and RSPF is what gives it freedom to roam.
-- Mike Bilow, <mikebw@ids.net> (Internet)
------------------------------
Date: Sun, 7 Feb 1993 22:34:39 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: Multi-Port RSPF
To: tcp-group@ucsd.edu
Actually, this is to Phil and Mike, and the interested tcp-group
readers...
>I'm not sure I like this new situation where Phil and Fred are starting
>to agree on moving RSPF below IP...
Don't worry, Mike, you don't have to worry... Phil and I don't agree.
I want RSPF parallel to IP, he wants it below.
Phil, Mike describes well why I don't want RSPF to be below IP.
I could certainly write a link-state protocol to run there, but it
would be Yet Another Competitor for TheNET, and not solve the IP
problem. The ARPAnet predates significant use of LANs anyway; in
those days (I was using it from '78), everybody was tied to a TIP or
IMP. Routing was whatever they felt like trying that month.
>In addition, the layering in the original proposal was not entirely clear,
>an issue which Fred and I have discussed previously on many occasions. For
>example, Fred strictly requires that the two main types of RSPF information,
>the "Router-to-Router Hello" and the "RSPF Update" frames, be sent above IP
>directly, effectively making RSPF its own Transport layer protocol. Aside
>from the seven-layer model, there really is no functional gain realized by
>doing this instead of, say, letting RSPF use a UDP socket, while the penalty
>in complexity and size of code is substantial.
I'm not terribly religious about this: If UDP sockets actually helped
without getting in the way of things like route testing, I'd not object.
But to me, that's a bigger violation of layering. RSPF is a routing
function, and I define that as being Network layer, while UDP is a
higher layer. Just because RSPF sits atop IP doesn't mean it leaves the
network layer -- it's simply another member of that layer. But IP does
tend to think strangely about that.
>On the other hand, RSPF uses
>conventional ICMP Echo Request messages ("pings") to test routes, which is
>the root of its problems, since this makes RSPF dependent upon another
>Transport layer protocol for its operation.
Pings are used because they can be sent to non-routers as well as to
routers, to establish IS-ES connectivity. Do you have an alternative
proposal?
>Multiport RSPF is not a minor problem. It is an impasse.
That's rather defeatist. IF it's realistic, then what do you propose
as an answer? Basically, I'm convinced and I think you are that
"IP Classic" routing, based on subnets, won't hack it on radio. So
we either fall into Phil's solution, of using a non-IP subnet to schlep
around IP frames among participating routers (and fight TheNET, ROSE,
and Plain AX.25), or we abandon IP. Now I admit that I originally
started on RSPF after being convinced to abandon a non-IP routing
protocol that I was developing for packet radio, after Mike Chepponis
got me in touch with tcp-group (ca. 1987). Do you suggest I go back to
a non-IP routing protocol? That's why I was proposing that we make
some changes to the layering assumptions in IP, by defining out the
subnet. It lets end systems think they're using IP, and in fact it is
IP except for the subnet concept. But of course it won't work using
IP Classic routing code.
Lesssee... AmTUBAnet?
fred k1io
------------------------------
Date: Sun, 7 Feb 93 22:06:00 -0800
From: Phil Karn <karn@qualcomm.com> (Phil Karn)
Subject: Multi-Port RSPF
To: karn@qualcomm.com, tcp-group@ucsd.edu,
At 7 Feb 1:39 -0500 (EST), MIKEBW@ids.net (Mike Bilow, ) wrote:
>RSPF actually doesn't fit into the layering model very well. Network
>routing is really at least a Network layer function, and it can be
>debated as to whether it should be considered a Transport layer function.
>However, a routing protocol is necessarily bound to the Network layer,
>in that RSPF becomes non-sensical unless it is used to route IP frames.
Well, maybe it doesn't fit into the ISO layering model very well,
but that doesn't mean it can't be done in a simple and elegant fashion.
Lots of real networks (one might say all!) don't fit into the ISO layering
model very well!
All you need is multiple network layers. That's the core idea of the Internet.
The upper network layer in the Internet is IP. Below IP you can have simple
links, or you can have entire complex networks. All IP expects (at least
traditionally) is a virtual subnet that appears to be fully connected. How
that network provides that internal connectivity is irrelevant. It could be
inherent, as in an Ethernet, or it could be an ARPANET, with its own
internal routing and network management algorithms. IP knows (or knew)
nothing about ARPANET, and ARPANET knew nothing about IP. They're distinct.
There's already precedent for this in AMPRNET: running IP atop NET/ROM. The
only problem is that NET/ROM itself is broken. All you have to do is to throw
it away and reinvent it properly.
The remainder of your post is simply a proof by contradiction (though you
may not realize it) that packet radio needs a distinct network layer.
Forget for the moment about IP and ARP. Just build a connectionless packet
radio network with callsigns as addresses, a link state algorithm for
routing, and in the end you'll actually support IP that much better.
Phil
------------------------------
Date: Mon, 8 Feb 93 09:26:17 GMT
From: Alan Cox <iiitac@pyr.swan.ac.uk>
Subject: Multi-Port RSPF
To: andyw@aspen.cray.com, tcp-group@ucsd.edu
XT's and disk and big routing tables.
An XT is more than capable of handling bit routing tables even mostly off
disk if the structure is sensible. It's like the domain.txt file which
also ought to be in a sensible record oriented format for speed...
ALan
------------------------------
Date: Sun, 7 Feb 93 11:08:33 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: NOS TEXT
To: tcp-group@ucsd.edu
Anyone want to guess how much NOS would reduce in size if all of the
text was taken out?? Probably a considerable amount. This WAS mentioned
before - storing the text in a file and using a token in NOS????
Doug
------------------------------
Date: Mon, 8 Feb 93 00:49:51 EST
From: ron@chaos.eng.wayne.edu (Ron Atkinson - N8FOW)
Subject: NTP and RDATE
To: tcp-group@ucsd.edu
With the latest discussion about NTP I dug through some disks and
found the NTP code for NOS that was out for the 910614 version. I
uploaded it to UCSD.EDU. I was going to put it in JNOS but after
looking briefly at it I decided I have other things to do :-)
Also the topic seemed to mainly be about running RDATE over packet
and not primarily over ethernet. I've been putting RDATE in JNOS for
quite a while (it's now in the released source) when I got it from another
ham in the group and used it primarily for users on packet to keep their
clocks somewhat accurate and at least within minutes of each other.
Regular packet is too slow for any accurate time, but it gets you in the
ball park. I ran NTP for a while on the internet just to play with it
and I always thought that it would be good for things like the packet
radio <> internet gateways to run on the internet side and RDATE on the
radio side. The gateway will be up most of the times anyways for it to
keep accurate time with the polling and a regular users on packet can
do an rdate when they first come up or periodic timed execution. With
the current packet radio network I couldn't see NTP being very practical
over it so that's why RDATE was used (plus just about every Unix system
has it in it so servers are widely available).
Ron N8FOW
------------------------------
Date: Sat, 06 Feb 1993 12:26:23
From: ccmcgone@mtu.edu (Charles McGonegal - N8OKM)
Subject: PE1CHL Help
To: tcp-group@ucsd.edu
I'm looking for infomation on the pe1chl version of Net.
1) Does anyone know where a version newer than 920420 is available for
anonymous ftp? The history file includes notes for versions past 920420,
but I haven't been able to find the code itself.
2) Can anyone direct me toward information on using the MIDI ports on an
Atari ST as a second serial port? The PE1CHL docs say that this is
possible, but not HOW.
Thanks.
Please reply to ccmcgone@mtu.edu
------------------------------
Date: Sat, 6 Feb 93 18:16:30 -0800
From: Phil Karn <karn@qualcomm.com>
Subject: rcs and source
To: <DEVANS%COLOLASP.BITNET@CORNELLC.cit.cornell.edu>
One major reason I release my RCS files is because they contain comments
I make as I update each file. Anyone who wants to see what has changed
lately can easily read them, and it saves me from having to remember
everything I have done since the last release (which I can never do
anyway). And just as important, it makes it much easier to reconcile
patches made by others, as they can just create a branch off my source
tree. And they can choose some version of a file other than the most
current, e.g., to avoid a recent change that breaks something in the
user's configuration.
I could upload both my RCS files and the latest sources extracted from them,
but this gets tedious over even a fast SLIP link. If the FTP server on
ucsd.edu supported my new XMD5 command, that would make the task *much*
easier. (Hint...)
What we *really* need, of course, is an FTP server that can do RCS
checkouts instead
of simple retrieves...
Phil
------------------------------
Date: Sun, 7 Feb 1993 22:46:57 -0500
From: chk@alias.com (C. Harald Koch)
Subject: rcs and source
To: tcp-group@ucsd.edu
Phil writes:
> What we *really* need, of course, is an FTP server that can do RCS
> checkouts instead of simple retrieves...
There are already FTP servers out there that support automated tar,
compress, uuencode, etc. of files. They use heuristics based on filename
(i.e. if I ask for dir.tar.Z and dir exists, ftpd runs the tar and compress
and feeds the output to me). Using one of these it should be easy to add
code that says "if a requested file doesn't exist, check for the RCS file
and check out the latest revision for transmission".
I think I have one of these FTP servers lying around; I'll take a look at it
and see how difficult the changes would be. Of course, this assumes that
Brian would be receptive to running a new ftp daemon on ucsd.edu... :-)
--
Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON
action, there is an equal | chk@alias.com (work-related mail)
and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address)
program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet)
------------------------------
Date: Sat, 06 Feb 1993 13:08:42 -0500
From: "Louis A. Mamakos" <louie@NI.umd.edu>
Subject: RDATE questions and comments
To: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
The protocol mentioned below is NTP (Network Time Protocol). If you
are at all serious about keeping good time, you really should take time
to read it to understand the techniques that it uses.
In short, NTP is a peer-to-peer or client-to-server protocol; it is
necessary to exchange packets in order to determine an estimated clock
offset and network delay. Consider a host "host" that want to know
what is clock offset and delay is with respect to host "peer". The
packet contains these 3 timestamps: the Originate, Received,
Transmitted and you maintain a state variable of the Peer_Received, of
the last time you received a packet from the peer.
So,
t3 = Originate, the time which a query was sent from "host"
t2 = Received, the time which the query was received at "peer"
t1 = Transmitted, the time the reply was sent from "peer"
t0 = Peer_Received, the time the reply was received at "host"
Note that t3 and t0 are using the "host" idea of a time scale, while
t2 and t1 are using the "peer" idea of a time scale. It is assumed
that these two are pretty close in frequency (that is, the rate at
which they advance) and differ mainly in phase (that is, the offset).
The clock offset can be determined by
(t2 - t3) + (t1 - t0)
offset = ---------------------
2
while round trip delay is simply
delay = (t0 - t3) - (t1 - t2)
The offset computation assumes that the network delay is symmetric,
otherwise a bias will be introduced into the computed clock offset.
If you want good time, then it is necessary to have multiple packet
exchanges, and then employ filtering techniques to discard anomolous
offset/delay samples, select amongst a number of clocks, etc. This is
what NTP does. It has a mode of operation where you continuously
exchange NTP polls with one or more reference clock, no more
frequently than every 64 seconds (and backing off to very 1024 seconds
or so) to estimate your clock's instrinsic drift rate.
It employs some rather sophisticated filtering techniques to select an
offset/delay from a set of 8 samples, as well as a model for how the
local clock is maintained. Note that if you want to have reliable
samples, you can't be shoving the clock around without invalidating
all of your saved samples, etc. Over a typical Internet WAN, it
should be possible to stay synchronized to within 20 milliseconds or
better.
Time hacking is way cool stuff. We just got in a Motorola GPS
receiver with a 1 pulse per second output, synchronized with UTC.
Claims specifications are within 100ns of the correct time. I will be
interesting to compare this with the WWVB clock that we have. Given
the two, we should be able to measure the changing height of the D
layer of the ionosphere which will change the propagation delay from
WWVB in Colorado to Maryland.
NTP is already accurate enought that I can resolve temperature
variations in my office by looking at the effect on the computed clock
drift rate as the computer's crystal oscillator changes frequency. Of
course, this is over multiple ethernet hops, not your typical crappy
AX.25 transport.
louie
WA3YMH
> Abount time synchronization: I don't know the protocol used for it,
> but know IP puts TTL in header and the TTL is used to count and limit
> time spent: assume packet was sent at 20:11:43 and has TTL 100, on
> destination it has TTL 43 and passed through 7 nodes, then we know it
> reached destination not later than 20:12:40 and not earlier than
> 20:12:33 (time spent on every node is rounded up to integer number of
> seconds and cannot be 0; it is simply subtracted from TTL of packet).
> However, I don't know a way for more precise synchronization.
> 73's, JT
------------------------------
Date: Sat, 6 Feb 93 19:18:08 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: RDATE questions and comments
To: "Louis A. Mamakos" <louie@NI.umd.edu>
> Message-Id: <9302061808.AA11829@sayshell.umd.edu>
> Subject: Re: RDATE questions and comments
> Date: Sat, 06 Feb 1993 13:08:42 -0500
The NTP is good assuming delay times are same in both directions.
And it is "nihil novi sub sole": the formula was described probably
more than century ago by a mathematician in short story:
"How to get accurate time when you noticed your home clock stopped"
- it was a long time ago, when there were no phones, watches and many
other useful thing and only several people in a city owned home clocks.
His advice: first make own clock go, look what time it shows, walk to a
friend having correctly set clock, look what time is on his clock, spent
some time talking with him, look at his clock again and go home, look on
own clock and then use the formula, finally add one minute spent on
computations to get accurate time home clock should be set to.
Of course need go with same speed in both directions...
On network: if packet is sent directly, delay is very small (70ms to
opposite side of Earth) and usually same in both directions, at least
on cable (on air it is not due to reflections in ionosphere, but
variations should not exceed hundreds of microseconds, usually less).
But if a packet is routed, delay on router can be large, and not same
for both directions. Use of TimeStamp ICMP is good when need sync time
with nearest node only, being useless otherwise (only if all inter-
mediate nodes attempt to sync time it may be good). I suppose TimeStamp
option can give better results assuming packets go same way in both
directions (seems there is an option to force path for packet) and
from time to time every node retransmits it almost immediately for
ANY direction (if there is always delay for one, result is wrong).
But: if packets are sent via radio line and one side needs 50ms for
transmitter to turn on and stabilize frequency and second 4ms only,
I see no way to eliminate 23ms bias caused by it.
> NTP is already accurate enought that I can resolve temperature
> variations in my office by looking at the effect on the computed clock
> drift rate as the computer's crystal oscillator changes frequency. Of
> course, this is over multiple ethernet hops, not your typical crappy
> AX.25 transport.
If there is constant bias in one direction your time is bad,
but you don't see it. 73's, JT (on ethernet, too)
------------------------------
Date: Sat, 6 Feb 1993 21:12:13 +0100 (MET)
From: rzm@oso.chalmers.se (Rafal Maszkowski)
Subject: RDATE questions and comments
To: tcp-group@ucsd.edu (tcp)
Jerzy Tarasiuk writes:
> However, I don't know a way for more precise synchronization.
Maybe ICMP time stamp request - if it was not discussed before.
R.
--
Rafal Maszkowski, rzm@oso.chalmers.se, rzm@mat.torun.edu.pl
NCU BBS (+48 56 14252, N81, MNP5, 2400)
Rafal.Maszkowski%p23.f1.n481.z2.fidonet.org%ncubbs@cc.ncu.edu.pl
------------------------------
Date: Sun, 7 Feb 93 11:04:36 EST
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: STAT
To: tcp-group@ucsd.edu
Here we go again.... can someone summarize the status of the STAT function.
I.E. where it works where it does not and possibly why? If I remember the
blame was never squarely placed with Borland? It sure would make life a lot
easier if it could be used in NOS.
I had a message a local about being able to CD to a file. Yes you can in
fact do that in NOS and in FTP because without using the STAT function
you can check for existence but not if it is a directory or file. I know
Johan recently stripped all stat stuff out using a function (filesize)
to determine filesize. Is there any hope of this ever being fixed?
Doug
------------------------------
Date: Mon, 8 Feb 93 11:13:14 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: Verifying have proper CPU for executable
To: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
I have read NetNews last time and found someone's msg about his
troubles with program modifying .EXE-s, he shown formula used to
compute loadable module size and told it is incorrect and he needs
to know correct formula. I looked into my program used to add CPU
checking code to an .EXE and found it uses bad formula, too.
Now it is fixed and good code is in ./CPU/CHKCPU2.ZIP on zfja-gate.
Difference in the program:
old eomm=(((long)(oldh.npag-1))<<9)|oldh.lpbc;
new eomm=(((long)oldh.npag)<<9)-((0x200-oldh.lpbc)%0x200);
(to be more strange, new header was set correctly by my program,
due to my another mistake; no need to change it) 73's, JT
------------------------------
Date: Sat, 6 Feb 93 23:06:13 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: XMODEM for NOS
To: nos-bbs@hydra.carleton.CA
I have completed porting xmodem to the NOS BBS. It is in beta test and
running well. It of course only works with tipmail connects - usually
via phone modem. I am using it with a 2400 baud phone modem. A number
of local users are currently running it thru it's paces and so far all
seems well.
The commands (tipmail only) are 'dx <filname>' and 'ux <filename>'
after which you get the normal xmodem messages.
The biggest problem in doing this was to put the tip code (input and
output) in totally raw mode. After getting around this the original
unix source was fairly easy to adapt to NOS, being that it has many
unix like commands - I.E. alarm.
I will SHARE this code probably early this coming week. It is based
on JNOS107B. Several modules are changed/added. The code adds about
1.5K to the compressed compiled size. It has a define in config.h.
This should be a nice addition to NOS allowing newcomers to log in
with any computer and modem and download the code.
If anyone wants to try this out on my system, send me private mail
and I will pass along the login details.
Doug
------------------------------
End of TCP-Group Digest V93 #37
******************************
******************************