Sanjeev Gupta via devel writes:
> Eric, next request. I have a spare parallel port on the system, could I
> have a software patch so that it can connect to a 10G optical WDM cable?
But that only works if you drill a hole exactly down the center of each
data wire in the parallel cable, you'll also
Hi,
I know that broadcast *client* mode was removed last year, because it was
impossible to secure.
Broadcast *server* mode was deprecated.
I have a feeling that was also removed, at some time. Has it?
--
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
Sanjeev Gupta via devel :
> I have a feeling that was also removed, at some time. Has it?
I do not recall that we explicitly removed it. But I wouldn't count on
it to work without testing.
--
http://www.catb.org/~esr/";>Eric S. Raymond
__
On Sun, Aug 18, 2019 at 7:35 PM Eric S. Raymond wrote:
> Sanjeev Gupta via devel :
> > I have a feeling that was also removed, at some time. Has it?
>
> I do not recall that we explicitly removed it. But I wouldn't count on
> it to work without testing.
>
The "Broadcast" item in ntpd/ntp_parse
Sanjeev Gupta :
> On Sun, Aug 18, 2019 at 7:35 PM Eric S. Raymond wrote:
>
> > Sanjeev Gupta via devel :
> > > I have a feeling that was also removed, at some time. Has it?
> >
> > I do not recall that we explicitly removed it. But I wouldn't count on
> > it to work without testing.
> >
>
>
>
e...@thyrsus.com said:
> Go ahead. Whatever broadcast code was left is pretty much a vermiform
> appendix, anyway.
The only leftovers that I know about are packet types. They may be used by
ntpq.
I remember a comment about there being no way to do broadcast securely. It
would be good to i
Hal Murray :
> I remember a comment about there being no way to do broadcast securely. It
> would be good to include an expanded version of that in the documentation.
That's covered. In the page on NTPsec changes:
* Broadcast- and multicast modes, which are impossible to
secure, have been rem
e...@thyrsus.com said:
> That's covered. In the page on NTPsec changes:
> * Broadcast- and multicast modes, which are impossible to
> secure, have been removed.
I was looking for more information. Why can't we secure it?
What's wrong with using a public/private key to sign each broadcast pa
On Sun, Aug 18, 2019 at 5:27 PM Hal Murray via devel
wrote:
>
> e...@thyrsus.com said:
> > That's covered. In the page on NTPsec changes:
> > * Broadcast- and multicast modes, which are impossible to
> > secure, have been removed.
>
> I was looking for more information. Why can't we secure it?
>> What's wrong with using a public/private key to sign each broadcast packet?
> However, there is not reasonable protection against delayed or replayed
> packets.
Thanks. That's what I was looking for.
--
These are my opinions. I hate spam.
_
Hal Murray :
>
> e...@thyrsus.com said:
> > That's covered. In the page on NTPsec changes:
> > * Broadcast- and multicast modes, which are impossible to
> > secure, have been removed.
>
> I was looking for more information. Why can't we secure it?
Daniel explained it to me once, but I've for
>> I was looking for more information. Why can't we secure it?
> Daniel explained it to me once, but I've forgotten the details. Perhaps he'll
> speak up.
The delay/replay problem is fatal, at least with a simple public key system
like I proposed.
There is probably something like a FAQ entry
12 matches
Mail list logo
