search

faucetsdn / daq

DEPRECATED -- DAQ (Device Automated Qualification) framework in no longer in use, supported, or maintained. It is here for archival purposes only.
Apache License 2.0
40 stars 32 forks source link

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

Open pisuke opened 3 years ago

grafnu commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 https://github.com/faucetsdn/daq/issues/845#issuecomment-827672941, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOTPYEWANBOPLXEJM7YPALTK3GHPANCNFSM423LD3OQ .

noursaidi commented 3 years ago

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 commented 3 years ago

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 https://github.com/faucetsdn/daq/issues/845#issuecomment-836452175, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIEPDYVSJUOPBB27WNMBTDTM6QMZANCNFSM423LD3OQ .

noursaidi commented 3 years ago

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 commented 3 years ago

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.

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 https://github.com/faucetsdn/daq/issues/845#issuecomment-836856142, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIEPDYREHJNA3TRFDBT46DTM75C5ANCNFSM423LD3OQ .