Bug 16970

Summary: inetd's internal time server will not talk to an HP4000M, firmware C.08.03
Product: [Retired] Red Hat Linux Reporter: John Bollinger <jobollin>
Component: netkit-baseAssignee: Crutcher Dunnavant <crutcher>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 6.2Keywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-01-19 21:19:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description John Bollinger 2000-08-25 21:13:29 UTC 
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.