Include the possibility to setup an NTP server using a hostname or IP address rather than have a hard coded NTP provided by DHCP #845
Comments
|
NB: This would be very similar functionality to what has been recently been done for 802.1x, which either uses the default internal radius server, or can be configured to use an external radius server (as configured by IP address somewhere). |
|
I think this is referring to device configuration of which NTP server to use rather than a test module. We don't strictly need a local DAQ NTP server, as the tests only check that (i) protocol is NTPv4 and (ii) the time between the NTP client and server is small enough that the client is considered to be synchronised. The second test currently also checks that the device is only communicating with the local DAQ NTP server as a pass condition, which is the functionality up for debate. The local DAQ NTP server runs on a random IP address with each run, so cannot be configured with this. I think the best solution is assigning a hostname to the NTP server (e.g daqntp.local?) in Dnsmasq. Then update the documentation so that the test operator configures the device to use this hostname as the NTP server. The benefit is that this also demonstrates that the NTP server on the device can be configured which is a desired behaviour. Alternatively, to keep tests testing one thing only, could become an INFO test and/or the NTP tests could allow communication with any NTP servers. However the the test logic will need to be revamped to track communication with different servers which may be in an NTP pool. |
|
The idea of pointing the device-under-test to the DAQ NTP server by setting
the hostname does sound good. So the existing tests would remain, and users
would (based on the capabilities of the device) either set the NTP server,
or let the device learn from DHCP based on what the device is capable of,
correct?
…On Tue, Apr 27, 2021 at 7:58 AM Noureddine ***@***.***> wrote:
I think this is referring to device configuration of which NTP server to
use rather than a test module. We don't strictly need a local DAQ NTP
server, as the tests only check that (i) protocol is NTPv4 and (ii) the
time between the NTP client and server is small enough that the client is
considered to be synchronised. The second test currently also checks that
the device is only communicating with the local DAQ NTP server as a pass
condition, which is the functionality up for debate.
The local DAQ NTP server runs on a random IP address with each run, so
cannot be configured with this. I think the best solution is assigning a
hostname to the NTP server (e.g daqntp.local?) in Dnsmasq. Then update the
documentation so that the test operator configures the device to use this
hostname as the NTP server.
The benefit is that this also demonstrates that the NTP server on the
device can be configured which is a desired behaviour. Alternatively, to
keep tests testing one thing only, could become an INFO test and/or the NTP
tests could allow communication with any NTP servers. However the the test
logic will need to be revamped to track communication with different
servers which may be in an NTP pool.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#845 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACOTPYEWANBOPLXEJM7YPALTK3GHPANCNFSM423LD3OQ>
.
|
|
My apologies @pbatta completely missed the notification. I suggest this test uses the hostname only. I understand the expectation is now that NTP through DHCP is not required? If we leave the DHCP support in there, I suggest we add add a test item which identifies if the device was configured using DHCP or via hostname. This would be a simple test, as it could just look for a DNS request for the hostname |
|
The problem is that the word "required" is not as binary as you might
think. The NTP-through-DHCP is an "intermediate" step that is OK for now,
but we should leave the other test in there. Ideally, they would both be
checked and have two separate line items... so the device is tested and
says if it passed "NTP/DNS" or "NTP/DHCP". Basically, the complete
requirement is "do NTP-through-DHCP unless explicitly acknowledged that it
only does NTP-through-DNS" -- so there would be a configuration parameter
in the module config file that says "this device is manually configured
with a static NTP server" (otherwise DHCP). It needs to explicitly
acknowledge its shortcomings.
…On Mon, May 10, 2021 at 2:20 AM Noureddine ***@***.***> wrote:
My apologies @pbatta <https://github.com/pbatta> completely missed the
notification.
I suggest this test uses the hostname only. I understand the expectation
is now that NTP through DHCP is not required? If we leave the DHCP support
in there, I suggest we add add a test item which identifies if the device
was configured using DHCP or via hostname. This would be a simple test, as
it could just look for a DNS request for the hostname
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#845 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIEPDYVSJUOPBB27WNMBTDTM6QMZANCNFSM423LD3OQ>
.
|
|
Thanks @grafnu, all understood and clear now. I think we can have both as separate test line items. This possibilities would be:
The overall NTP category will pass if the above pass condition is met. Then confirm whether a device passed NTP/DNS or NTP/DHCP, we can either:
@grafnu is there a preference? I think (2) might be more reliable, as there is a chance the DNS request could come in-between startup.pcap completing and monitor.pcap starting, but might require a framework change |
|
I think the line-items look good, but the logic behind them is a bit off, I
think. It has to do with the configuration parameter and what it defines.
The configuration parameter should be "first" in the logic chain and
dictate overall expectations.
- If a "NTP server" config parameter is supplied, then it would be the
NTP/DNS mode, with pass/fail being if the device uses the indicated server
or not (and skip if not configured).
- If no "NTP server" config is supplied, then it would be NTP/DHCP, with
pass/fail being if the device uses the indicated server or not (and skip if
configured for NTP server)
- Skip/skip then would be if no packets were detected (regardless of
configuration).
Your 2nd (fail/skip) line was odd because it was something where the config
parameter was not supplied, but I think that's not quite right.
…On Mon, May 10, 2021 at 8:41 AM Noureddine ***@***.***> wrote:
Thanks @grafnu <https://github.com/grafnu>, all understood and clear now.
I think we can have both as separate test line items. This possibilities
would be:
NTP/DNS NTP/DHCP
Pass Skip DNS Configuration parameter in module config added and
configured with correct static NTP server
Fail Skip Device configured with correct static NTP server but
configuration parameter in module config *not* added; or wrong NTP server
used
Skip Pass Device uses NTP server from DHCP
Skip Fail Device did not use NTP server from DHCP
Skip Skip No NTP packets detected
The overall NTP category will pass if the above pass condition is met.
Then confirm whether a device passed NTP/DNS or NTP/DHCP, we can either:
1. Look for a DNS request
2. Have two IP addresses, one via DHCP and one via DNS, and look for
respective IP address
@grafnu <https://github.com/grafnu> is there a preference? I think (2)
might be more reliable, as there is a chance the DNS request could come
in-between startup.pcap completing and monitor.pcap starting, but might
require a framework change
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#845 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIEPDYREHJNA3TRFDBT46DTM75C5ANCNFSM423LD3OQ>
.
|
No description provided.
The text was updated successfully, but these errors were encountered: