Date: Tue, 15 Jun 93 04:30:09 PDT
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 #154
To: tcp-group-digest
TCP-Group Digest Tue, 15 Jun 93 Volume 93 : Issue 154
Today's Topics:
(oops!) JNOS 1.09 for Linux re-uploaded to ucsd.edu
ampr hosts file (4 msgs)
ampr hosts file UCSD.EDU
Digital audio: CVSD or CELP. Chipset suggestions?
NOS POP3 and POP2 servers (2 msgs)
password in IP timestamp option ? (2 msgs)
Password security (3 msgs)
Re: ampr hosts file UCSD.EDU
UK Co-ordinators
WAMPES bug fixed
xms.asm compile error (2 msgs)
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: Mon, 14 Jun 1993 09:59:16 -0400
From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
Subject: (oops!) JNOS 1.09 for Linux re-uploaded to ucsd.edu
To: ka9q-unix@knuth.mtsu.edu, nos-bbs@hydra.carleton.ca, tcp-group@ucsd.edu,
Well, I made several mistakes in uploading this yesterday, including but not
limited to putting it in the wrong incoming directory and omitting the
instructions for "attach asy" under Linux/Unix. It's not in tcpip/incoming
with a proper README in the archive. I also found and fixed a smallish
problem myself... I hadn't noticed that 1.09's dochat() expects nonnull
arguments, so TTYCALL broke.
++Brandon
--
Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org
It's not too late to turn back from the "Gates" of Hell...
Linux: the free 32-bit operating system, available NOW. Why waaaaaait for NT?
------------------------------
Date: Mon, 14 Jun 93 13:22:31 BST
From: A.D.S.Benham@bnr.co.uk
Subject: ampr hosts file
To: TCP-Group@UCSD.Edu
>Date: Fri, 11 Jun 93 23:43:09 CET
>From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
>Subject: ampr hosts file UCSD.EDU
>To: TCP-GROUP <TCP-GROUP@ucsd.edu>,
>Hi just looked again at the amprhosts file on ucsd.edu, last look 6 months ago,
>seems that its vastly out of date.. since im interested in Uk and German
>IP's, I have a vested interest, When and how often do the IP coordinators
>mail copies of the IP hosts of their domain to the World domain list
>namely UCSD.EDU, I think Brian at that address ?
>The German IP hosts is about 6 months out of date.. the UK IP hosts is
>Years behind !! My own IP is not even in the list and i have had this ip
>number for 2.5 years now.
>Come On Lads!! can we keep the amprhosts up to date with WW coord!
>Can one trust it?? If your on a Internet worm hole and DNS dont have the Info
>Then WHAT,? hmmmm
>Thanks. Barry.
On a related subject....
In Southern England we're running a hub experiment, and we realised that trying
to keep =everyone's= host file up-to-date wasn't going to work.
So most of the hubs now run DNS, so their users don't need a hosts file at all.
The problem we've run into is that because the "ampr.org" domain is flat, there's
no way that we can set up a DNS with authority for the range of addresses that it
issues.
For example, my local hub issues addresses in the range 44.131.19.192 - 44.131.19.223
and therefore his DNS should have authority for hostnames mapping to addresses in that
range.
But with a flat domain, there's no practical way to distinguish between "g8fsl.ampr.org"
and "zl9zzz.ampr.org" - only one of which my local hub has authority for. So we're
stuck with every hub trying to keep an up-to-date hosts file.. and hopefully not
getting it from ucsd.edu...
Is there a reason why "ampr.org" is a flat domain? Would it be generally helpful to
sub-divide it into continents/countries/regions? (For example, the Internet apparently
routes all net-44 traffic to the USofA. So if I send Internet mail to "g8fsl.ampr.org"
it will go 3000 miles (+) in the wrong direction first, and then probably get stuck).
What I'm thinking of is something along the lines of changing from "g8fsl.ampr.org" to
"g8fsl.ldn.uk.ampr.org" to indicate I'm in the London sub-domain of the United Kingdom
sub-domain of "ampr.org". Then we can set up a DNS with authority for "*.ldn.uk.ampr.org".
I'm told it can't be done. I'm told "ampr.org" is flat. But I'm not told why.
All I'm trying to do is to improve the situation, so that we don't need every ampr.org
host to have a host file that contains every other host that connectivity exists for
(which would be one big file, covering East, South-East and Southern England, and however
much of the USA that can be reached through the London <> New York link).
Andrew Benham
--------------------------------------------------------------------
adsb@bnr.co.uk BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA
adsb@bnr.ca +44 279 402372 Fax: +44 279 402029
Home: g8fsl@g8fsl.ampr.org [44.131.19.195] G8FSL@GB3XP
--------------------------------------------------------------------
------------------------------
Date: Mon, 14 Jun 93 11:34:36 CDT
From: andyw@aspen.cray.com (Andy Warner)
Subject: ampr hosts file
To: tcp-group@ucsd.edu (TCP Group)
> [...]
> I'm told it can't be done. I'm told "ampr.org" is flat. But I'm not told why.
> All I'm trying to do is to improve the situation, so that we don't need every ampr.org
> host to have a host file that contains every other host that connectivity exists for
> (which would be one big file, covering East, South-East and Southern England, and however
> much of the USA that can be reached through the London <> New York link).
As long as we don't forget that names are not routes, why can't we do
whatever makes the most sense ? I don't see why we need to get hooked
up on dogma. Locally we have <callsign>.tcman.ampr.org, and we run
2 or 3 nameservers for that suffix, if our internet link was working
we wouldn't need to do this, but it's not..
So far we've used this "administrative domain" for a specific
geographic area, but we're currently thinking about what to do
when we go state-wide (mn.usa.ampr.org ? - hmmm, that doesn't
sound right, does it ?) Large corporate internets tend to be
split this way, at least internally, don't they ?
--
andyw. (N0REN/G1XRL)
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Mon, 14 Jun 93 22:23:03 EDT
From: "Ross Patterson" <n4yyh@wa2hee.ampr.org>
Subject: ampr hosts file
To: A.D.S.Benham@bnr.co.uk
On Mon, 14 Jun 93 13:22:31 BST, <A.D.S.Benham@bnr.co.uk> wrote:
>Is there a reason why "ampr.org" is a flat domain? Would it be generally helpful to
>sub-divide it into continents/countries/regions? (For example, the Internet apparently
>routes all net-44 traffic to the USofA. So if I send Internet mail to "g8fsl.ampr.org"
>it will go 3000 miles (+) in the wrong direction first, and then probably get stuck).
Changing the names won't fix this, you need to change to a network number
that doesn't advertise its primary connection via the USA. There's no law
that says you have to be part of net 44, although it is next to impossible
to get a Class A (i.e. X.*.*.*) or Class B (X.Y.*.*) network address these
days. There's no reason why the UK couldn't have a Class C (X.Y.Z.*)
address of its own, and still have hostnames in the AMPR.ORG domain.
The difference between network numbers and domain names is subtle, and
confuses many supposed experts. From the very beginning, the idea has been
that domain names implement some "natural" grouping of hosts, such as all
the Amateur Radio stations, while network numbers implement the routing of
packets (datagrams to IPers) between hosts. Just because two hosts share
a common network number doesn't mean they are at all related. And just
because two hosts share a common domain name doesn't mean they are
located anywhere nearby each other. My favorite example is that of
Stanford.Rutgers.Edu, located in Palo Alto California, and
Rutgers.Stanford.Edu, located in New Brunswick New Jersey. Each was located
3000 miles from its "home" domain, and had a network address on its
"guest"network.
>What I'm thinking of is something along the lines of changing from "g8fsl.ampr.org" to
>"g8fsl.ldn.uk.ampr.org" to indicate I'm in the London sub-domain of the United Kingdom
>sub-domain of "ampr.org". Then we can set up a DNS with authority for "*.ldn.uk.ampr.org".
This works, but only sort-of. When you move to the Outer Hebrides, you don't
want your hostname to change to g8fsl.solitary-rocks.uk.ampr.org. But if
you can get IP connectivity between DNS servers, you can have as many
authoritative servers for a domain as you want, reducing the need for
geographic locators in names. Depending on software capabilities, you may
need to FTP the DOMAIN.TXT file around, or it may happen automagically via
the "zone transfer" facility.
>I'm told it can't be done. I'm told "ampr.org" is flat. But I'm not told why.
Gee, that's the easiest question you've asked so far. Brian Kantor, the
registered "owner" of AMPR.ORG, wants it that way. Several folks have
offered to set up authoritative servers for sub-domains, and each has been
rebuffed. From what I hear, Brian feels responsible for the domain, and
wants to keep it under his control so he can fix it if it gets broken. And
as far as the Network Information Center (NIC) is concerned, he IS
responsible, so I guess that makes it his decision.
73,
Ross N4YYH
------------------------------
Date: Tue, 15 Jun 93 13:54:36 +1000
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: ampr hosts file
To: andyw@aspen.cray.com (Andy Warner), tcp-group@ucsd.edu (TCP Group)
>> I'm told it can't be done. I'm told "ampr.org" is flat. But I'm not told why.
Domains work by having one server have a portion of the whole database.
For example, ucsd.edu holds the database for the portion
XXXX.ampr.org
This is `flat' because the whole of the ampr.org domain is kept by ucsd.edu.
If, instead it was broken into geographic sub-domains, we could have it
spread over many places, e.g
minnie.vk1xwt.act.au.ampr.org
would be served by a DNS looking after XXXX.vk1xwt.act.au.ampr.org. We would
need other servers to look after
XXXX.act.au.ampr.org
XXXX.au.ampr.org, and
XXXX.ampr.org
The advantages of this approach is that the databases are maintained locally,
and theoretically they are up to date. Also, a breakdown at one DNS does
not stop DNS information from other portions.
The disadvantages is that without 24/day solid DNS servers for each domain
interconnected by reliable links, you would never be able to reliably resolve
domain names. Also, we would need to convert the current database of
callsign.ampr.org names to the new system.
I would suggest that we don't have the capability of fully sub-domaining
the entire .ampr.org domain yet, because of unreliable DNS/links.
However, areas with reliable DNS/links have the capability of partitioning
off their domain space from ucsd.edu if they wish to. Brian Kantor would
have to agree to this, he would need to get ucsd.edu to `know' about
the partitioning.
Warren vk1xwt
------------------------------
Date: Mon, 14 Jun 93 13:15:27 BST
From: john <John.Heaton@nessie.mcc.ac.uk>
Subject: ampr hosts file UCSD.EDU
To: markw@icsbelf.co.uk (Mark Willis)
> The previous UK coordinator, g6phf, did not have internet access.
^^^^^
it was g6pwy
> There is a new coordinator as of a few months ago, g1plt. I am not sure
> wether he is able to update the database.
Yep!, he does have access.
John
--
John Heaton - NRS Central Administrator
MCC Network Unit, The University, Oxford Road, Manchester, M13-9PL
Phone: (+44) 61 275 6011 - FAX: (+44) 61 275 6040
Packet: G1YYH @ G1YYH.GB7PWY.#16.GBR.EU
------------------------------
Date: Mon, 14 Jun 93 08:51:56 mdt
From: ka7oei@uugate.wa7slg.ampr.org
Subject: Digital audio: CVSD or CELP. Chipset suggestions?
To: tcp-group@ucsd.edu
One of the uses for our developing high-speed packet network in Utah will
be digital voice/repeater linking. To that end we are looking for
some CODEC chips to handle voice compression.
They MUST be able to pass DTMF and CTCSS tones with audio for the old-
fashioned controllers that might be at the far ends.
Does anyone have comments on the CVSD codecs around? Their data rates
are a bit higher than we would like, but perfectly useable. We are
especially interested in the CELP stuff (The 8kbps audio channel) stuff
but have no insight on the what chipsets would be both affordable and/or
worth pursuing...
I'd love comments on this...
<Clint>
ka7oei@uugate.wa7slg.ampr.org
clint@uugate.aim.utah.edu
ka7oei@wb7ulh (ax.25 stuff...)
------------------------------
Date: Mon, 14 Jun 1993 09:45:24 -0600 (CST)
From: "Erik Olson" <erik@marge.phys.washington.edu>
Subject: NOS POP3 and POP2 servers
To: TCP-Group@UCSD.Edu, ashok@biochemistry.BIOC.CWRU.Edu
[Ashok writes]
>I have recently (today) come across a couple POP3 clients that seem to use
>lower case commands (eg. "user" instead of "USER" etc.), and therefore not
>work with the Erik Olson's POP3 server for NOS.
You should write to the author of those POP3 clients and tell them to get
their act together; The RFC (1081 & the other one) specifically says
commands are to be sent in UPPER CASE! Completely counter to RFC822 (SMTP)
which explicitly says to accept either.
However, the bugfix follows Phil Karn's advice, "Accept liberally, send
conservatively".
- Erik
---
Erik Olson (in lab) erik@marge.phys.washington.edu
University of Washington olson@phys.washington.edu
Cosmic Ray Lab, Phys. 405
------------------------------
Date: Mon, 14 Jun 93 12:48:35 CST
From: "Ashok Aiyar" <ashok@biochemistry.BIOC.CWRU.Edu>
Subject: NOS POP3 and POP2 servers
To: erik@marge.phys.washington.edu
On Mon, 14 Jun 1993 09:45:24 -0600 (CS, Erik Olson wrote:
>[Ashok writes]
>>I have recently (today) come across a couple POP3 clients that seem to use
>>lower case commands (eg. "user" instead of "USER" etc.), and therefore not
>>work with the Erik Olson's POP3 server for NOS.
>
>You should write to the author of those POP3 clients and tell them to get
>their act together; The RFC (1081 & the other one) specifically says
>commands are to be sent in UPPER CASE! Completely counter to RFC822 (SMTP)
>which explicitly says to accept either.
I agree fully. I also checked RFC 1081, and RFC 1225. Both these clients
are "beta-test" Winsock clients ....
>However, the bugfix follows Phil Karn's advice, "Accept liberally, send
>conservatively".
I don't call it a bug-fix, since the bug isn't in your POP3 server, but
rather in the client's implementation of POP3. Nonetheless, I noticed that
Berkeley popper seems to accept upper, lower and mixed-case commands, and
also University of Minnesota pop2d.c (pop2 daemon) does the same.
Sorry, I didn't mean to offend you. I have actually written to the author
of one client, but mail to the other one seems to bounce.
Best wishes,
Ashok
----------------------------------------------------------------------
Ashok A. Aiyar
Department of Biochemistry
CWRU School of Medicine
----------------------------------------------------------------------
------------------------------
Date: 14 Jun 93 17:02:07 GMT
From: Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk>
Subject: password in IP timestamp option ?
To: tcp-group@ucsd.edu
Hi,
I've been reading RFCs in my search to find a way to insert
a password into an IP packet header. I think I may have found a way.
Firstly I note that no NOS code I have yet looked at implements
the timestamp ip header option, but all honour the ip.optlen
setting.
The timestamp usage is as follows
0 8 16 24 28 <- start-bit
option_code length pointer oflow+flag
32 bit timestamp
32 bit timestamp
....
where option_code = 68 indicates a timestamp.
length = number of octets in option starting at option_code (so min
value = 4). pointer = next free octet (min val = 5).
oflow = number of gateways that could not add a timestamp 'cos
pointer > length when they got the packet. flag indicates
whether the gateway adds time_stamp of IPaddress+timestamp.
The timestamp is normally some standard setting but can be a
local time setting if this standard value is not available as
long as the high order bit of the timestamp is set.
Anyway what I'm thinking of putting onto the non gateway NOS code
is this
if (ismyaddress(ip.source))
{
int32 p1,p2 ;
uchar oflow = 0 ;
ip.options[0] = 68 ; /* timestamp */
ip.options[1] = 12 ; /* giving me 64 bits */
ip.options[2] = 13 ; /* which I am going to use up */
getpassword(&p1, &p2) ; /* ps,p2 are DES encryptions */
if (!(p1 & 0x80000000L))
{
p1 |= 0x80000000L ; /* ensure high bit set */
oflow |= 1 ; /* mark so gateway can undo */
}
if (!(p2 & 0x80000000L))
{
p2 |= 0x80000000L ;
oflow |= 2 ;
}
put32(ip.options+4, p1) ; /* fill 32 bits assigned by length */
put32(ip.options+8, p2) ; /* fill remaining 32 bits */
ip.options[3] = (oflow << 4) | 0 ; /* flag = 0 */
}
This way I am not encrypting any data, all the values are
possible, all digipeating nodes will pass on the packet
unaffected till it reaches the net-44 gateway.
The gateway can then verify the ip.source sender is a permitted user
of the gateway. I think this will work as long as none of the
digipeating nodes alter oflow. Even if they did I could still get
the gateway to decrypt all four versions of the password (with or
without the high bit set to find the correct one).
Can anyone see any major flaws in this reasoning ?
In particular using this method means that you could not use
any of the ip options such as record route, or strict source
routing,.... Are these options used at all for anything in IP
or by other higher level protocols in NOS. I feared that ping might
use them but have been told that that uses ICMP packets.
Thanks
JJ
:: Jon Jagger , Sheffield Hallam University, S1 1WB, UK
:: Work J.R.Jagger@shu.ac.uk Home 2E1BSD (44.131.2.111)
:: Tel 0742 533802/432889 (work/home) Fax 0743 533840
:: Newspaper ad: Men wanted for expanding contracting company!
------------------------------
Date: 14 Jun 93 17:02:07 GMT
From: Jon Jagger <J.R.Jagger@sheffield-hallam.ac.uk>
Subject: password in IP timestamp option ?
To: tcp-group@ucsd.edu
Hi,
I've been reading RFCs in my search to find a way to insert
a password into an IP packet header. I think I may have found a way.
Firstly I note that no NOS code I have yet looked at implements
the timestamp ip header option, but all honour the ip.optlen
setting.
The timestamp usage is as follows
0 8 16 24 28 <- start-bit
option_code length pointer oflow+flag
32 bit timestamp
32 bit timestamp
....
where option_code = 68 indicates a timestamp.
length = number of octets in option starting at option_code (so min
value = 4). pointer = next free octet (min val = 5).
oflow = number of gateways that could not add a timestamp 'cos
pointer > length when they got the packet. flag indicates
whether the gateway adds time_stamp of IPaddress+timestamp.
The timestamp is normally some standard setting but can be a
local time setting if this standard value is not available as
long as the high order bit of the timestamp is set.
Anyway what I'm thinking of putting onto the non gateway NOS code
is this
if (ismyaddress(ip.source))
{
int32 p1,p2 ;
uchar oflow = 0 ;
ip.options[0] = 68 ; /* timestamp */
ip.options[1] = 12 ; /* giving me 64 bits */
ip.options[2] = 13 ; /* which I am going to use up */
getpassword(&p1, &p2) ; /* ps,p2 are DES encryptions */
if (!(p1 & 0x80000000L))
{
p1 |= 0x80000000L ; /* ensure high bit set */
oflow |= 1 ; /* mark so gateway can undo */
}
if (!(p2 & 0x80000000L))
{
p2 |= 0x80000000L ;
oflow |= 2 ;
}
put32(ip.options+4, p1) ; /* fill 32 bits assigned by length */
put32(ip.options+8, p2) ; /* fill remaining 32 bits */
ip.options[3] = (oflow << 4) | 0 ; /* flag = 0 */
}
This way I am not encrypting any data, all the values are
possible, all digipeating nodes will pass on the packet
unaffected till it reaches the net-44 gateway.
The gateway can then verify the ip.source sender is a permitted user
of the gateway. I think this will work as long as none of the
digipeating nodes alter oflow. Even if they did I could still get
the gateway to decrypt all four versions of the password (with or
without the high bit set to find the correct one).
Can anyone see any major flaws in this reasoning ?
In particular using this method means that you could not use
any of the ip options such as record route, or strict source
routing,.... Are these options used at all for anything in IP
or by other higher level protocols in NOS. I feared that ping might
use them but have been told that that uses ICMP packets.
Thanks
JJ
:: Jon Jagger , Sheffield Hallam University, S1 1WB, UK
:: Work J.R.Jagger@shu.ac.uk Home 2E1BSD (44.131.2.111)
:: Tel 0742 533802/432889 (work/home) Fax 0743 533840
:: Newspaper ad: Men wanted for expanding contracting company!
------------------------------
Date: Mon, 14 Jun 93 17:32:06 +0200
From: jt@fuw.edu.pl
Subject: Password security
To: samisen!djc@sol.UVic.CA, tcp-group@ucsd.edu
I have rewritten some of MD5 code (MD5Transform function) in assembly
- speed increased over 3 times on every machine, now MD5Transform times
are: < 8 ms on slow 4.77MHz XT, < 1 ms on 12MHz AT, < 700 us on 16MHz
386, < 170 us on 16MHz 386 with use of 32-bit registers.
(I will make the assembly code available when I finish it).
On Intel CPU-s initializing 16 bytes + one MD5Transform + moving result
(16 bytes) constitute full MD5 for fixed-length data up to 55 bytes
(if more data is to be processed the MD5Transform must be invoked once
for every 64-byte block). The multiple MD5 hashing of password can be
done in the following way: put password (up to 55 bytes) in buffer,
append padding and length to it, init the 16 bytes, MD5Transform(),
put padding and new length in buffer starting from offset 16, and now
for every hash must move 16 bytes, init 16 bytes, MD5Transform().
Since can use quite large hash counts (even thousands on 386).
To Mike Bilow: don't afraid someone will unhash MD5 digest, even when
its input length is known, seems MD5 really well mixes bits... 73's
------------------------------
Date: Mon, 14 Jun 93 10:01:20 PDT
From: djc@samisen.UVic.CA
Subject: Password security
To: tcp-group@ucsd.edu
> From: MIKEBW@ids.net (Mike Bilow, <sol.UVic.CA!ids.net!MIKEBW>)
>
> Your recursive password scheme is very interesting, but I think it has
> a potential vulnerability. All passwords S(i) where i > 0 are known to
> ...
This criticism is quite valid. What it all boils down to is that
MD5 is not designed for this application. I am not a crytographer so
I chose MD5 because it was convenient, free, and fast. There are other
one-way hash algorithms (Snefru?) - maybe someone out there can suggest
a more suitable replacement.
Mind you, there aren't any cryptographers trying to crack passwords
on my network and this method, even as it is, is far, far better than
all the other schemes I have actually seen in use.
--
/\/\/\/\/\/
Doug Collinge, try: sol.uvic.ca!samisen!djc
or: samisen!djc@sol.uvic.ca
or: dcolling@ve7frg.ampr.org
VE7GNU PBBS: VE7GNU@VE7VBB.#ISLAND.BC.CAN.NOAM
------------------------------
Date: Mon, 14 Jun 93 13:21:05 EDT
From: "William Allen Simpson" <bill.simpson@um.cc.umich.edu>
Subject: Password security
To: tcp-group@ucsd.edu
The method of sending a Challenge value, and returning a MD5 hash
response based on a the challenge, a message number, and a
secret/password, is well documented in RFC-1334, PPP Authentication
Protocols.
No passwords are sent over the link. It's easy to use and maintain as
long as there are a small number of users.
I am working on extending this to Kerberos and PEM certificates, for
sites with tens of thousands of users.
Bill.Simpson@um.cc.umich.edu
------------------------------
Date: Mon, 14 Jun 93 18:27:17 MST
From: w6swe@w6swe.tapr.org (Bob Nielsen)
Subject: Re: ampr hosts file UCSD.EDU
To: tcp-group@ucsd.edu
Which file is this, anyway? The only list I could find a few months ago had
only addresses which seemed to be reachable through gateways (or at least I
assumed that was what it was---I've had an address for about 3 years and
wasn't listed).
------------------
Bob Nielsen, W6SWE Internet: w6swe@tapr.org
Tucson, AZ Amateur IP: 44.124.12.16
AX.25: w6swe@wb7tls.az.usa.na
------------------------------
Date: Mon Jun 14 17:47:42 1993
From: iiitac@pyr.swan.ac.uk
Subject: UK Co-ordinators
To: tcp-group@ucsd.edu
Well if the UK co-ordinator isn't on the internet surely
a) He can send updates to Brian via packet
b) He could send them to someone in the UK to forward onto the internet.
That's not a major chore surely - I'll even volunteer if none of the
actual co-ordinators want to do it.
Alan
------------------------------
Date: Mon, 14 Jun 93 14:27:10 MDT
From: Dieter Deyke <deyke@mdddhd.fc.hp.com>
Subject: WAMPES bug fixed
To: tcp-group@ucsd.edu
I have uploaded a new version of WAMPES (wampes-930614) to UCSD.EDU.
This version fixes a severe stack overflow problem in the 930610 version
of WAMPES. You may either pull the new archive from
ucsd.edu:.../incoming, or apply the following patch manually.
In the file src/login.c, change the line
char bitmap[MAXUID+1];
to be
static char bitmap[MAXUID+1]; /* Keep off the stack */
Sorry for the inconvenience,
Dieter
------------------------------
Date: Mon, 14 Jun 93 08:21 EDT
From: "James C Mankin (814)-863-4348" <N5X@PSUVM.PSU.EDU>
Subject: xms.asm compile error
To: nx2b%nx2b.ampr.org@UCSD.EDU
>When compiling jnos 1.10x1 with the 386 option, XMS.ASM displays
>the error "Operand types do not match".
>.Does anyone have a fix for this?
>Thanks,
>Steve Dorfman NX2B
Since XMS isnt supposed to work anyway, I got rid of that error by
replacing XMS.ASM with a file containing only one line of
END
Seemed to work OK. 73's Jim kb3kj
------------------------------
Date: Mon, 14 Jun 93 16:50:42 +0200
From: jt@fuw.edu.pl
Subject: xms.asm compile error
To: nx2b@nx2b.ampr.org, tcp-group@ucsd.edu
> Date: Mon, 14 Jun 93 00:29:31 GMT Message-Id: <2769@nx2b.ampr.org>
>
> When compiling jnos 1.10x1 with the 386 option, XMS.ASM displays
> the error "Operand types do not match".
> The line with the error reads -
> lds si, buf
I suppose the buf is arg to procedure and its definition has different
meaning for 32-bit CPU - look for "proc" followed by "arg ...,buf:<type>,..."
Either the type must be changed (if it doesn't match definition in caller's
code) or "LDS ESI,buf" must be used for 32-bit CPU (if you use large memory
model with 32-bit addressing because have >4 Gigabytes RAM). 73's, JT
------------------------------
End of TCP-Group Digest V93 #154
******************************
******************************