Danny A. van Delft <[log in to unmask]> wrote:


>Guess what happened: The DTC was reset, there was the "download
>started for DTC ..." message on the console of the 939, but, suprise,
>suprise, also on the console of the 937. After the usual delay the 939
>declared a succesful load of the DTC, while the 937 complained after a
>while: "download aborted". I repeated the process for the other dtc's
>and they all loaded succesful from the 939.
>
>Well, I might have been lucky, perhaps the 939 beat the 937 in
>responding to the download request, but perhaps the dtc only listened
>to the originating MAC address. Don't know, don't really care, but
>willing to learn if someone has the answer.

Hey, learning is what it's all about!

>It makes you wonder
>though, this is a potential security risc: anyone with a HP3000 and
>knowledge of the DTC addresses can pull the rug under the legitimate
>HP3000. Farfetched, I know.


When the DTC completes it's self test it sends out a packet over the network
requesting a download. The packet contains the download request and the DTCs
MAC address. The HP3000s know how to interpret this packet and immediately
check for this MAC address in their internal configuration. If this is a DTC
that the machine is supposed to control then it will respond to the DTC and
dowload to it. Presumably the 939 can do these tasks much faster than a 937,
so it responded first. Due to system loading issues you can't guarantee that
a better performing machine will respond first.

I wouldn't be concerned about the security risk. I can't see anybody making
the effort to clone a DTC when there are so many other security holes
already (telnet, packet sniffing, clear-text passwords...)

>
>In retrospect, I shouldn't have been suprised by the download started
>message on the 937, as the dtc was also known (of course) to this
>system.
>


That is correct. Both systems received the download request. You should have
received another console message on the 937 indicating the download had
timed-out.

HTH.

Doug.

Doug Werth                                     Beechglen Development Inc.
[log in to unmask]                                       Cincinnati, Ohio

The opinions expressed do not necessarily represent the views or opinions
of Beechglen Development. They might, but not necessarily. They represent
solely the opinions of the author.