[patch] ntpd rejects source UDP ports less than 123 as bogus
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
NTP |
Fix Released
|
High
|
|||
ntp (Debian) |
Fix Released
|
Unknown
|
|||
ntp (Ubuntu) |
Fix Released
|
Medium
|
Kick In | ||
Precise |
Fix Released
|
Medium
|
Eric Desrochers | ||
Trusty |
Fix Released
|
Medium
|
Eric Desrochers | ||
Wily |
Fix Released
|
Medium
|
Eric Desrochers | ||
Xenial |
Fix Released
|
Medium
|
Kick In |
Bug Description
[Impact]
If an NTP client sends a request with a source port less than 123, the packet is silently ignored by ntpd. This is occurring in our environment due to NAT.
[Development Fix]
Fixed by merge of NTP of newer upstream release that includes the fix. Stuck in dep-wait in xenial-proposed due to an unrelated issue (pps-tools MIR or other resolution).
[Test Case]
The problem can easily be reproduced by having an iptable postrouting nat forcing the source port to be under 123 set on the client.
Setup:
==> NTP server = y.y.y.y
ntp.conf configured to be a server.
==> NTP client = x.x.x.x
"ntpdate" used to submmit requests
#iptable setup to force src port to be lower than 123
iptables -t nat -A POSTROUTING -p UDP --dport 123 -j SNAT --to-source x.x.x.x:100-122
## On the client, set to force src port < 123 (without patch)
$ ntpdate y.y.y.y
ntpdate[<PID>]: no server suitable for synchronization found
## On the client, set to force src port < 123 (with patch)
$ ntpdate y.y.y.y
ntpdate[<PID>]: adjust time server y.y.y.y offset -0.028483 sec
[Regression Potential]
The patch comes from upstream: http://
A testfix[1] package has been provided to the community before the SRU process to bring more confidence for the patch. Positive feedbacks has been given by the community to confirm the patch addressed the bug [comment #7]
[1]- https:/
[Original description]
[Title copied from Debian bug, which was not filed by me. Description below is mine.]
If an NTP client sends a request with a source port less than 123, the packet is silently ignored by ntpd. This is occurring in our environment due to NAT.
Attached is the patch already accepted upstream which fixes the issue. I've verified it fixes the problem. Debian has been ignoring this patch for almost 3 years. Can we get this in Ubuntu please?
Changed in ntp: | |
importance: | Unknown → High |
status: | Unknown → Fix Released |
Changed in ntp (Debian): | |
status: | Unknown → New |
Changed in ntp (Ubuntu Precise): | |
importance: | Undecided → Medium |
Changed in ntp (Ubuntu Trusty): | |
importance: | Undecided → Medium |
Changed in ntp (Ubuntu Wily): | |
importance: | Undecided → Medium |
Changed in ntp (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in ntp (Ubuntu Precise): | |
assignee: | nobody → Eric Desrochers (slashd) |
Changed in ntp (Ubuntu Trusty): | |
assignee: | nobody → Eric Desrochers (slashd) |
Changed in ntp (Ubuntu Wily): | |
assignee: | nobody → Eric Desrochers (slashd) |
Changed in ntp (Ubuntu Xenial): | |
assignee: | nobody → Kick In (kick-d) |
Changed in ntp (Ubuntu Xenial): | |
status: | New → In Progress |
Changed in ntp (Ubuntu Wily): | |
status: | New → In Progress |
Changed in ntp (Ubuntu Precise): | |
status: | New → In Progress |
Changed in ntp (Ubuntu Trusty): | |
status: | New → In Progress |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
tags: | added: sts |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
tags: |
added: verification-done-trusty removed: verification-done |
Changed in ntp (Debian): | |
status: | New → Fix Released |
Per Dave Hart, I'm filing this bug report to track an issue where NTP client packets on the inside of a Cisco IOS NAT box are dropped by ntpd on the outside of the Cisco IOS NAT box. This is due to IOS NAT using a low UDP source port ntp_proto.c tests against and blocks.
This was worked around per David's suggestion in the thread below, but it would be great if this would make it into mainline code.
http:// groups. google. com/group/ comp.protocols. time.ntp/ msg/3024d073b91 4b278