Plusnet Hub 2 config

[#1]

Would it not be correct to say that 24:00:00 does not exist in an operating systems time settings but 23:59:59 (hh:mm:ss) and as the date changes the time rolls over to 00:00:00 ?

[#2]

What settings did you chose in the web interface?

12am to 12 pm didn't work for me. (Half a solution)

Selecting 12am to 12am resulted in a 00;00 - 00:00 effectiveness (as seen/reported in the helpdesk webpage, and not just the gooey which is where the selection occurs).

The helpdesk webpage indicates 00:00 - 24:00 effectiveness for the default group. Sometimes you have to cross-check what is selected with what is reported.

I'm thinking that if you set up other 'groups' (group as you will) and move all known devices into those groups and then block the 'default' group and then wait for a new device and see what happens you may get/see a different outcome. You have to actually use the devices to test the effectiveness.

[#3]

Right, so what we're saying is that despite being able to create a replica of the default group, the inner workings are actually applying a rule that covers a zero time period, unlike the default rule that accurately covers a 24hr window?

And secondly, creating a custom group that only blocks the 12hr period between 12am and 12pm, assigning devices to it and configuring to block, does not see traffic restricted on those devices during the 12hr active window?

Have I got that right?

FYI, I'll not be able to revisit this until after the Jubille as my network is being used to test something else at the moment.

[#4]

Point 1.

Essentially, yes. I'm looking at the event log and what actually happens.

When refreshing the firewall rules the default group has a timespan of 00:00 - 24:00 (this is reported in the event log when any another group is created or updated, even if the default group had not been changed).

Use the web interface to try to replicate that (12am - 12am?) it gets recorded as 00:00 - 00:00 when the firewall rules are refreshed (clicking the 'save' button).

Using a timeframe of 12:00am - 11:45pm does appear to function. The system event log reports when the firewall rules are refreshed/updated that the effective timespan is 00:00-23:45.

Point 2.

When using the web interface to create a timespan for a group of 12am - 12pm the firewall rules get updated and the event log (using a 24hr clock) reports the effective timespan as 00:00 - 12:00.

Then to monitor it you have to watch the counters as reported by the webinterface, or lay direct hands on the device. My test devices are Alexas as they are plugged in and can be rebooted pretty much at will. The pretty coloured lights (if they are correct) confirm that they've received an IP allocation from the gateway. Then a simple voice command confirms whether they get WAN-side.

No sweat on testing. Whenever. I'll just have to find local work-arounds. I fully understand that you've got your local (personal) 'testlab' and there are multiple calls on it (quite possibly more important than this).

[#5]

System times resolve to a much finer detail that a second. Otherwise how can ping report milliseconds?

[#6]

The point I was making is 24:00:00 does not exist on a PC clock. 

I did check on my TP-Link router, it does show a setting for 00:00 to 24:00 in the drop down when setting up a access rules but when applied it changes to 00:00 to 00:00

[#7]

How it is interpreted/represented may very well be down to hover it is implemented on the machine.

All I can say is that entering 00:00am - 00:00am via the webface results in a filter which has no active time period.

00:00am - 23:45pm gives a filter that is active for all but 15 minutes.

The web interface is interpreting the end 00:00am as being the same 00:00am as the start.

The firewall events in the log report the default filter as having an active period of 00:00 - 24:00

Attempts to add a similar group using 00:00am - 00:00am results in the firewall event showing an active period of 00:00-00:00 (and that is what it is - the start and finish time are the same).

If the web interface gave the option of 23:59:59.99 then perhaps it wouldn't be so confusing/mildly irritating. Or a start time and elapsed period of time.

Semantics: 24:00 today is the same as 00:00 tomorrow.

Other sematics: using the local time without reference to GMT or BST.

I used to work in a place that liked to keep the logfiles/events of certain systems in the current DST timeframe. Spring was fine. Autumn was resulting in events which happened at a different time but shared the same timestamp. Despite arguing against it (like 'why not keep the raw logs in GMT and alter the user interface to display GMT and BST as part of the timestamp), the change that was eventually implemented to prevent this happening was to use a (very low level) system service to alter the processor clock speed and filter in the time change over a period of time (rather than letting it happen in one go at 02:00)

[#8]

@greygit 

I am not going to discuss or assist you any further, I find you arrogant and rude

[#9]

Well, it would be. But it seems that 00:00 - 00:00 can be interpreted in two distinct ways.