а если установить прошивку 1.9.2.7-d и выбрать свой корректный часовой пояс с учетом DST?
Printable View
theMIROn, перешиваться с 1.9.2.7-10 ради эксперимента с этой фичей что-то не хочется. Если скажете, что точно работает - перешьюсь.
Таймзона стоит EET-2EEST,M3.5.0/3,M10.5.0/4 (я в Украине).
А если без скриптов, в самом роутере как присвоить IP к МАК адресу конкретному чтобы тот не мог поменять IP, точнее мог но ничего не работало, только под тем который я дал и потом просто тупо заблочить все порты по времени на данный IP. У меня такая мысль :) Так вроде проще или ...? :rolleyes:
Вы хотите сказать, что настройки DST в TZ мне нужно убрать, оставить дефолтные, тогда ipt_time будет срабатывать вовремя?
И в чем радость, если остальной софт будет работать неправильно? Или в 1.9.2.7-d все эти проблемы уже решены и TZ можно объявлять глобально без DST и все работает?
Сейчас у меня в pre-boot содержится:Работает корректно всё, кроме ipt_time. Ну, и настроек TZ из вэб-морды, естественно :)Code:TZ="EET-2EEST,M3.5.0/3,M10.5.0/4"
nvram set time_zone="$TZ"
echo "$TZ" > /etc/TZ
Если уж Вы на этом форуме и в роутере прошивка Олега, то ответ "НЕТ", не проще.
вероятно нет. Но проверить это кому-то все же придется. Если действительности соответствует, то можно открыть issue на googlecode.Quote:
в 1.9.2.7-d все эти проблемы уже решены и TZ можно объявлять глобально без DST и все работает?
а до меня не дошло.
Т.е. все же надо дважды в год переписывать правила? Проблема эта давно и многократно поднималась (т.е. ИМХО она существует :) ):
http://wl500g.info/showpost.php?p=91215&postcount=48
http://wl500g.info/showthread.php?t=16441
al37919, ну, насколько я понял, имеется ввиду, что для ipt_time время нужно задавать без учета DST, при этом оно (которое написано в правилах) должно зимой соответствовать системному, а летом должно быть на 1 час меньше.
Тем не менее, ipt_time будет (должен или хз) обрабатывать события в соответствии с системным временем.
Осенью посмотрим :)
Легко увидеть, что ipt_time пытается использовать localtime и системную зону sys_tz. Однако, вполне возможно, что какой-то кусок кода написан некорректно...
правильно, и тогда будет и зимой и летом отрабатывать правилно.
Оно считает с GMT.
Когда задаем время, оно прописывается, как есть. задаем летом - с учетом смещения, зимой - нет.
А вот из ядра время расчитывается без смещения, от GMT.
Варианта решения 3:
1. задавать время в параметрах сразу с поправкой на смещение, чтобы сравнение было верным.
2. при проверке времени пакета корректировать время на летнее смещение и сравнивать с параметрами. В итоге будет работать медленнее для каждого пакета, соответствующего условию
3. корректировать параметры сразу и, обязательно, при смене зимнего/летнего времени, плюс при выводе делать обратную корректировку.
а это все дофига делов, обработчик писать...
sys_tz используется только для расчета таймштампа относительно GMT из поля tz_minuteswest.
поле tz_dsttime не используется (оно вообще deprecated btw), да и dst смещение нужно будет рассчитывать типа вот так:
об этом варианте я и говорил в п.2Code:gettimeofday(0, &tz);
timeshift=tz.tz_minuteswest*60;
Добрый день, подскажите пожалуйста, при выполнении команды
iptables -I FORWARD 1 -o ppp0 -m time --timestart 23:00:00 --timestop 22:45:00 --days Mon,Tue,Wed,Thu,Fri,Sun,Sat -m mac --mac-source хх:хх:хх:хх:хх:хх -j DROP,
выводится сообщение iptables: Invalid argument, команда
iptables -I FORWARD 1 -o ppp0 -m mac --mac-source xx:xx:xx:xx:xx:xx -j DROP выполняется нормально. xx:xx:xx:xx:xx:xx - нужный MAC.
Роутер D-Link DIR-320, прошивка от sorine
http://rapidshare.de/files/46627396/...c-229.rar.html. Куда копать?
Спасибо за быстрый ответ, вечером попробую.