[464] in Zephyr_Bugs
["Richard Basch" : Zephyr server fixes]
daemon@ATHENA.MIT.EDU (Mark Curby)
Thu Mar 25 12:06:17 1993
Date: Thu, 25 Mar 93 12:06:35 EST
From: mlc@MIT.EDU (Mark Curby)
To: bug-zephyr@MIT.EDU
for the archive...
------- Forwarded Message
Date: Thu, 25 Mar 1993 11:27:31 -0500
To: dcns@MIT.EDU, css@MIT.EDU, acs@MIT.EDU, athena-ws@MIT.EDU
Subject: Zephyr server fixes
From: "Richard Basch" <basch@MIT.EDU>
1. A new server is in place that restricts the faking that has been
occurring; if the source address is not that of your client when it
is being sent, the message will not be delivered. There is only
ONE exception: a person may substitute 0.0.0.0 as the source address
in the packet if the zephyrgram is authentic. This permits people
to remain hidden (like their exposure setting).
Note: a client is not being made available that does this by default,
since these fields were never intended to originally be used as a
tracking mechanism. The fields were intended to tag a unique message
id to each packet for the benefit of the Zephyr servers, and if multple
messages have the same unique id, the delivery of the messages will be
unreliable. Previously it used the source address and the timestamp.
Given that the source address was then over-used for tracing, we had
to stamp down on it. If lots of people start delivering messages from
0.0.0.0 at the same time, message delivery will certainly be unreliable.
2. I am currently working on a fix to a debilitating problem for Zephyr.
If a user has a zwgc running and (and a hostmanager is running) and does:
% unsetenv DISPLAY; zctl load; zctl unhide
% setenv DISPLAY
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxx
% zctl load; zctl unhide
all the Zephyr servers coredump. Basically, the hostmanager does not
receive the acknowledgement from the server because it coredumped, and
then proceeds to try the next server, causing it to die, and so on...
This is, needless to say, rather debilitating, and as it stands,
untraceable. I have a partial fix, but in my opinion it still needs
some work, because the bad packet is still getting a positive ack. In
fact, I have to still work on the error propogation.
This has been the cause of two of the Zephyr server deaths in the past
two weeks.
-----
Why am I sending this? Because, I got a lot of flak for when people
thought they were not well-informed. I am only debugging the problem,
so I might as well let people know what is going on. I expect that the
server installation timing is based on Operations, so when this will be
fixed is a combination of:
- when I get around to cleaning up my fixes.
- when I get around to handing it off to Operations.
- when they have a chance to install it.
and subject to delays if people have objections to this fix.
As it stands, anyone can crash the Zephyr servers and not leave a trace
as to who is attacking the system. It was reported to me by one person
who managed to kill the servers by accident, and suspected as much.
-Richard
------- End of Forwarded Message
