Bug 16970 - inetd's internal time server will not talk to an HP4000M, firmware C.08.03
inetd's internal time server will not talk to an HP4000M, firmware C.08.03
Product: Red Hat Linux
Classification: Retired
Component: netkit-base (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2000-08-25 17:13 EDT by John Bollinger
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-19 16:19:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Bollinger 2000-08-25 17:13:29 EDT
This is not a bug, but I am reporting it for the record in case anyone else runs into it.

My HP Procurve 4000M switch has an option to synchronize its clock to a
time (RFC 868) server.  I enabled the internal time service in inetd (the switch
uses the UDP flavor) on my RedHat 6.2 box, but the switch reported that it
was unable to contact the server.  The server, on the other hand, logged
internal failures (exit code -1) to the syslog every time the switch polled it.  It
turns out that the switch was using source port 4, and a quick check of the
inetd source shows that its internal services gratuitously reject UDP requests
from privileged ports.  Apparently inetd's internal time server is unusual in
this regard, for HP seemed unaware of the problem.  Nevertheless, I think
inetd's behavior is reasonable.

The best solution would be for HP to fix their firmware, and I have contacted
them about it, but it is unclear whether they will do so any time soon.  I
originally solved the problem by writing my own standalone RFC 868 server
(which wasn't as picky as inetd's), but after I figured out what was going on
I was able to patch inetd to let in time requests from source port 4.  I do not
provide the patch here, as I don't necessarilly consider it to be a reasonable
solution, but I can provide it upon request.

Note You need to log in before you can comment on or make changes to this bug.