Include the possibility to setup an NTP server using a hostname or IP address rather than have a hard coded NTP provided by DHCP about daq

[grafnu]

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).

[noursaidi]

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.

[pbatta]

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> .

[noursaidi]

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

[grafnu]

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> .

[noursaidi]

Thanks @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 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

[grafnu]

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> .