1. Для блокировка используем

[zhenya`]

вероятно это backlog. sysctl -a | grep backlog

[taf_321]

А там точно надо sysctl крутить? У меня решилось кручением параметра max_pending_packets в nfqfilter.ini

[zhenya`]

лучше и там и там ) на всякий.

[hsvt]

2016-05-23 21:12:07.528 [9896] Fatal Application - Bad url format in line 26671

 

betcity.xn--fiq228c5hs/

betcity.???

betcity.Д╦╜Ф√┤Г╫▒

 

-- Logs begin at Mon 2016-05-23 22:49:55 MSK. --
May 23 19:50:14 nfqfilter systemd[1]: Starting Nfqilter filtering daemon...
May 23 19:50:14 nfqfilter systemd[1]: Started Nfqilter filtering daemon.
May 23 20:03:48 nfqfilter systemd[1]: Stopping Nfqilter filtering daemon...
May 23 20:03:48 nfqfilter systemd[1]: Starting Nfqilter filtering daemon...
May 23 20:03:48 nfqfilter systemd[1]: Started Nfqilter filtering daemon.
May 23 21:03:54 nfqfilter systemd[1]: Stopping Nfqilter filtering daemon...
May 23 21:03:54 nfqfilter systemd[1]: Starting Nfqilter filtering daemon...
May 23 21:03:54 nfqfilter systemd[1]: Started Nfqilter filtering daemon.
May 23 21:03:54 nfqfilter systemd[1]: nfqfilter.service: main process exited, code=exited, status=70/n/a
May 23 21:03:54 nfqfilter systemd[1]: Unit nfqfilter.service entered failed state.
May 23 21:03:54 nfqfilter systemd[1]: nfqfilter.service failed.

 

В БД с виду вроде бы норм всё:

 

| 29287 | 2016-05-23 20:35:22 |     29172 | https://betcity.xn--fiq228c5hs               |           |
| 29371 | 2016-05-23 20:35:24 |     29258 | http://www3.bkbetcity.com                    |           |
| 29527 | 2016-05-23 20:35:27 |     29414 | https://www3.bkbetcity.com                   |           |
| 29543 | 2016-05-23 20:35:27 |     29431 | http://betcity.xn--fiq228c5hs

 

Может какие то доп. проверки на урлы бы?

Изменено 23 мая, 2016 пользователем hsvt

[overty]

Тоже "рухнул" сегодня

Fatal Application - Bad url format in line 26662 in file /urls

betcity.???

betcity.中文网

 

Здесь мне кажется просто не хватает слешей на конце.

 

Падает еще из-за строки tcp:16869@SSL в файле protos

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---

rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0

tgkill(23627, 23627, SIGABRT) = 0

--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=23627, si_uid=0} ---

+++ killed by SIGABRT +++

Аварийный останов

Изменено 23 мая, 2016 пользователем overty

[nma]

В реестре есть записи с длиной домена больше 60 символов.

Например:

Added new domain: www.shaman-r.ru.legalnyye-narkotiki-sol-dlya-vann-dzhiviash.reagenty-kuritelnyye-smesi-geroin-efedrin-metadon-lsd-mdma-jwh.biz

 

В таблице zap2_domains, поле domain - varchar(60) NOT NULL

[taf_321]

В таблице zap2_domains, поле domain - varchar(60) NOT NULL

 

alter table zap2_domains CHANGE domain domain varchar(255);

 

Здесь мне кажется просто не хватает слешей на конце.

Дело не в слэше, а в "???".

[nma]

В таблице zap2_domains, поле domain - varchar(60) NOT NULL

 

alter table zap2_domains CHANGE domain domain varchar(255);

 

 

Это то понятно, я для max1976 неплохо бы подправить в исходниках.

[taf_321]

Там уже поправлено.

 

2max1976: даже с коммитом ffe42ea3d650df626142ba6b613d3b6f00b5571b в файл urls прорывается "betcity.???"

[taf_321]

Подрывается вот на этом URL: http://betcity.xn--fiq228c5hs

[overty]

Просмотр сообщенияoverty (Вчера, 22:08) писал:

Здесь мне кажется просто не хватает слешей на конце.

 

Дело не в слэше, а в "???".

 

У Вас может в вопросах, у меня точно в слешах, проверял добавляя их.

Начинает запускаться и падает по сигналу SIGABRT из-за строки tcp:16869@SSL в файле protos.

[oret]

Добавление слэшей в конце URL в таблице zap2_urls для record_id 29193 и 29309 решают проблему, но эти записи скорее всего перезапишутся при следующем запуске zapret.pl

 

UPD

Да, так и есть, record_id 29193 перезаписывается без слэша и nfqfilter падает.

Изменено 24 мая, 2016 пользователем oret

[dnvk]

oret, на record_id ссылаться смысла нет. они у всех разные.

искать нужный, видимо, следует запросом:

select * from zap2_urls where url like '%betcity.xn%';

мне выдаёт:

| 27340 | 2016-03-28 22:08:54 |     26701 | http://betcity.xn--6frz82g/             |           | 
| 27189 | 2016-03-25 23:08:02 |     26555 | http://www.betcity.xn--6frz82g/         |           | 
| 27274 | 2016-03-25 23:08:03 |     26641 | https://www.betcity.xn--6frz82g/        |           | 
| 26962 | 2016-03-22 23:08:04 |     26333 | https://betcity.xn--6frz82g/            |           | 
| 28976 | 2016-04-15 21:08:09 |     28313 | http://wap.betcity.xn--6frz82g/         |           | 
| 28981 | 2016-04-15 21:08:09 |     28318 | http://wap.betcity.xn--6frz82g/bets.php |           | 
| 32431 | 2016-05-23 22:57:41 |     31670 | http://betcity.xn--fiq228c5hs           |           | 
| 32704 | 2016-05-23 22:57:43 |     31946 | https://betcity.xn--fiq228c5hs          |           | 

тот же dig все домены определяет нормально, с иероглифами.

 

косяк в модуле перла?

[dnvk]

не, перл тут не при делах. это ж было специально внедрённое "каверканье" записей, чтобы система отлавливала "кривые" запросы проверяльщиков.

[overty]

А по строке tcp:16869@SSL в файле protos ни у кого проблемы нет?

[oret]

| 32431 | 2016-05-23 22:57:41 |     31670 | http://betcity.xn--fiq228c5hs           |           |

| 32704 | 2016-05-23 22:57:43 |     31946 | https://betcity.xn--fiq228c5hs          |           |

Получается, загвоздка именно в этих записях (после добавления слэшей работает). Перл я совсем не знаю, так что не могу сказать в чем проблема...

[dnvk]

overty, такая строка есть. nfqfilter с ней запускается. Но у меня используется древняя версия nfqfilter. Так что я тут не показатель.

[oret]

А по строке tcp:16869@SSL в файле protos ни у кого проблемы нет?

У меня последняя версия nfqfilter: проблемы с запуском из-за этой строки нет.

[max1976]

Исправлена последняя проблема с подготовкой url.

[oret]

Исправлена последняя проблема с подготовкой url.

Спасибо, max1976, все работает.

[overty]

Пока вбил костыль sed -i '/\//! {s/.*/&\//}' ./urls

Перед запуском nfqfilter ищу строки без "/" и добавляю слэш. Вроде запускается.

 

А вот что у меня не так с protos не пойму?

 

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---

rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0

tgkill(9022, 9022, SIGABRT) = 0

--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=9022, si_uid=0} ---

+++ killed by SIGABRT +++

Аварийный останов

[AN111]

По IPv6 в make_files.pl и в квагге:

В make_file.pl некорректно распознаются IPv6 адреса (с одним упрощением в записи ":0:" на "::") из существующего конфига квагги,

это приводит к перезаписи тех же адресов.

 

Причина:

Квагга в своем конфиге меняет формат записи ipv6 адреса из 7-ми групп с одной упрощенной группой (с заменой :0: на ::) - на полную запись IPv6 (без :: - из 8-ми групп)

 

Нужно приведение IPv6 к общему строковому формату или сравнивать новые и старые IPv6 не строками.

 

Пример:

Список на удаление (из текущего конфига)

no network 2a00:e460:2a00:c01d:7ea:0:12:67e/128

no network 2001:4801:7901:0:aff8:a2d8:0:631/128

no network 2001:67c:4e8:fa60:3:0:811:138/128

no network 2a01:430:d:0:2cc:ffff:fe20:c22f/128

no network 2a00:1ed0:1:1800:1:0:d688:2d77/128

no network 2607:5300:60:3ab7:ffff:ffff:0:2f/128

список на добавление:

network 2607:5300:60:3ab7:ffff:ffff::2f/128

network 2001:4801:7901::aff8:a2d8:0:631/128

network 2a00:1ed0:1:1800:1::d688:2d77/128

network 2001:67c:4e8:fa60:3::811:138/128

network 2a01:430:d::2cc:ffff:fe20:c22f/128

network 2a00:e460:2a00:c01d:7ea::12:67e/128

 

 

P.S.

Нужно ли "close($wtr);" в make_files.pl ?

[max1976]

По IPv6 в make_files.pl и в квагге:

В make_file.pl некорректно распознаются IPv6 адреса (с одним упрощением в записи ":0:" на "::") из существующего конфига квагги,

это приводит к перезаписи тех же адресов.

 

Причина:

Квагга в своем конфиге меняет формат записи ipv6 адреса из 7-ми групп с одной упрощенной группой (с заменой :0: на ::) - на полную запись IPv6 (без :: - из 8-ми групп)

 

Нужно приведение IPv6 к общему строковому формату или сравнивать новые и старые IPv6 не строками.

 

Пример:

Список на удаление (из текущего конфига)

no network 2a00:e460:2a00:c01d:7ea:0:12:67e/128

no network 2001:4801:7901:0:aff8:a2d8:0:631/128

no network 2001:67c:4e8:fa60:3:0:811:138/128

no network 2a01:430:d:0:2cc:ffff:fe20:c22f/128

no network 2a00:1ed0:1:1800:1:0:d688:2d77/128

no network 2607:5300:60:3ab7:ffff:ffff:0:2f/128

список на добавление:

network 2607:5300:60:3ab7:ffff:ffff::2f/128

network 2001:4801:7901::aff8:a2d8:0:631/128

network 2a00:1ed0:1:1800:1::d688:2d77/128

network 2001:67c:4e8:fa60:3::811:138/128

network 2a01:430:d::2cc:ffff:fe20:c22f/128

network 2a00:e460:2a00:c01d:7ea::12:67e/128

 

Об этом я знаю, пока не думал как это победить.

 

Нужно ли "close($wtr);" в make_files.pl ?

 

Нужно, без этого процесс общения с vtysh не завершится.

[AN111]

У меня новый скрипт подвисает на выполнении.

Причина не в этом, а в самом vtysh. Видимо при большом количестве изменений он подвисает. Второй и последующий запуски проходят без проблем, т.к. изменений мало.

 

В борьбе с подвисаниями vtysh попробовал в zebra увеличить буфер на прием - с ключом -s 2097152

Не помогло (да и ключ немного не к этому)

На малых изменениях в IP скрипт проходит, если очищаю всю таблицу ipv4 в квагге - скрипт подвисает.

Количество принятых на бордере маршрутов ~ 1124 до подвисания.

 

Изменил запись конфига:

Примитивно вместо $wdr от open2 пишу конфиг во внешний файл, затем обычным system подаю его на вход vtysh (вместо open2())

open( CONF, ">/tmp/vtysh.conf" );

system("/bin/cat /tmp/vtysh.conf | /usr/bin/vtysh" > /dev/null 2>&1) == 0 or die "system: vtysh failed: $?";

 

Проходит без проблем.

Может проблема с подвисанием в IPC::Open2 ?

[max1976]

У меня новый скрипт подвисает на выполнении.

Причина не в этом, а в самом vtysh. Видимо при большом количестве изменений он подвисает. Второй и последующий запуски проходят без проблем, т.к. изменений мало.

 

В борьбе с подвисаниями vtysh попробовал в zebra увеличить буфер на прием - с ключом -s 2097152

Не помогло (да и ключ немного не к этому)

На малых изменениях в IP скрипт проходит, если очищаю всю таблицу ipv4 в квагге - скрипт подвисает.

Количество принятых на бордере маршрутов ~ 1124 до подвисания.

 

Изменил запись конфига:

Примитивно вместо $wdr от open2 пишу конфиг во внешний файл, затем обычным system подаю его на вход vtysh (вместо open2())

open( CONF, ">/tmp/vtysh.conf" );

system("/bin/cat /tmp/vtysh.conf | /usr/bin/vtysh" > /dev/null 2>&1) == 0 or die "system: vtysh failed: $?";

 

Проходит без проблем.

Может проблема с подвисанием в IPC::Open2 ?

 

Попробуйте измененный скрипт. На всякий случай я добавил чтение вывода vtysh.

Изменено 24 мая, 2016 пользователем max1976