In some cases it could be nice to have a "countdown timer" with a rule like with address list members,You could use the note feature for that. Enter reason why each rule is made.
my whish is to get an "time"-object which I can add to any firewall-rules. The tiime-object should have an beginning and an end-datetime.In some cases it could be nice to have a "countdown timer" with a rule like with address list members,You could use the note feature for that. Enter reason why each rule is made.
to temporarily open some thing without risk to forget to remove it later, but I do not consider it important
enough to make it into a feature request. The comment feature already is a very nice advantage of
RouterOS over competing products and even operating systems.
Well that is already available, but it appears that it allows only cyclic definitions and no date fields. That can probably be fixed rather easily.my whish is to get an "time"-object which I can add to any firewall-rules. The tiime-object should have an beginning and an end-datetime.
Somehow... it should be available as an own "object", just like the adress-list. If so, I can add several named "time-objects" and add them to te corresponding rules.Well that is already available, but it appears that it allows only cyclic definitions and no date fields. That can probably be fixed rather easily.
time
This matches if the packet arrival time/date is within a given range.
All options are optional, but are ANDed when specified. All times are
interpreted as UTC by default.
--datestart YYYY[-MM[-DD[Thh[:mm[:ss]]]]]
--datestop YYYY[-MM[-DD[Thh[:mm[:ss]]]]]
Only match during the given time, which must be in ISO 8601 "T"
notation. The possible time range is 1970-01-01T00:00:00 to
2038-01-19T04:17:07.
If --datestart or --datestop are not specified, it will default
to 1970-01-01 and 2038-01-19, respectively.
--timestart hh:mm[:ss]
--timestop hh:mm[:ss]
Only match during the given daytime. The possible time range is
00:00:00 to 23:59:59. Leading zeroes are allowed (e.g. "06:03")
and correctly interpreted as base-10.
[!] --monthdays day[,day...]
Only match on the given days of the month. Possible values are 1
to 31. Note that specifying 31 will of course not match on
months which do not have a 31st day; the same goes for 28- or
29-day February.
[!] --weekdays day[,day...]
Only match on the given weekdays. Possible values are Mon, Tue,
Wed, Thu, Fri, Sat, Sun, or values from 1 to 7, respectively.
You may also use two-character variants (Mo, Tu, etc.).
--contiguous
When --timestop is smaller than --timestart value, match this as
a single time period instead distinct intervals. See EXAMPLES.
--kerneltz
Use the kernel timezone instead of UTC to determine whether a
packet meets the time regulations.I know this from shorewall, It is really a nice feature and a nice addition to Mikrotik and I'd appreciate also this smaller solution.That functionality is not available in netfilter I think, so it would have to be implemented entirely in the management layer.
Just a guess - did you enable fasttrack?hi guys,
does anyone of you encountered problems in PCC after upgrading their Mikrotik OS?
PCC currently is not working anymore after upgrading . please help.
Confirm - at 6.38 (and possibly earlier, updated from 6.37) fasttrack is broken, dynamic rules are in "passtrough", as well as on devices that do not support this feature. Downgrade to 6.37 recovers it.After upgrading to 6.38, my pppoe connection to WAN speed test makes cpu go to 100%. FastTrack counters seem OK --> FastTrack seems to be configured properly.
Because of the cpu, the router no longer gets 300 mbps at 45% of CPU. Now I get up to 200 mbps at 100%.
UPDATE4I might have found some other IPsec related bugs:
1. sometimes the new "PH states" are not correct, traffic is flowing but there is "no PH2" or "ready to send" which often only reverts after phase1 rekey or new phase2
2. if the initiator is reconnecting too fast e.g. after PPPoE 24 hour reconnect and the old SAs are not flushed on responder, the initiator thinks he is connected and has SAs but the responder has an invalid policy and no traffic can flow.
EDIT
If a peer reconnects after PPoE 24h disconnect within DPD timeout and with a another IP address than before, there will be the situation described in 2.,
I tested this by setting delay before attempting to reconnect to a value greater than the DPD timeout which "solved" the problem. Bit this is clearly not the expected behaviour.
UPDATE
even my workaround did not solve the problem
UPDATE2:
now again a second reboot after the upgrade seems to solve this problem for now (testet with a script doing disable+enable)
UPDATE3
second reboot does not solve this for long. after two days the problem is back. responder shows invalid dynamic policy while initiator thinks that he is connected.
as usual, please fix
thank you in advance
No.does this fix the out of order packets on the CCR models when using the encryption hardware acceleration?
