Доброе время суток. У меня возникла необходимость добавить в ядро поддержку модуля IMQ. Система - ASPLinux 9.2 . Скачал свежие исходники ядра 2.4.31, пропатчил их соответствующим патчем с www.linuximq.net, взял .config от старого ядра (2.4.22), в make menuconfig включил поддержку imq непосредственно в ядро. Скомпилировал, установил, загрузил новое ядро. Модуль вроде заработал, по команде

ip link set imq0 up

в системе поднимался новый интерфейс. Но после этого перестал работать подгружаемый модуль ядра ip_queue (он у меня перехватывал пакеты у ядра и заворачивал их в демон учета трафика). На команду modprobe ip_queue система среагировала так:

/lib/modules/2.4.31/kernel/net/ipv4/netfilter/ip_queue.o: init_module: Device or resource busy

Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters.

You may find more information in syslog or the output from dmesg

/lib/modules/2.4.31/kernel/net/ipv4/netfilter/ip_queue.o: insmod

/lib/modules/2.4.31/kernel/net/ipv4/netfilter/ip_queue.o failed

/lib/modules/2.4.31/kernel/net/ipv4/netfilter/ip_queue.o: insmod ip_queue failed

В /var/log/messages нашел запись:

kernel: failed to register queue handler

Попробовал ядро скомпилить по другому: ip_queue и imq сделать в виде подгружаемых модулей. Та же самая проблема возникла теперь уже при загрузке imq : Device or resource busy и т.д. Когда же я скомпилил оба модуля непосредственно в ядро, при последовательном прохождении трафика через цели iptables QUEUE и IMQ система намертво зависала(проверял, пуская черен них ftp-трафик и заходя с удаленной машины на локальный ftp-cервер). Кто-нибудь может сказать, как эти модули заставить корректно работать друг с другом? Вообще такое возможно? Кто-нибудь такую схему реализовывал ( последовательно заворачивать трафик сперва в QUEUE, а затем в IMQ)?

Доброго всем времени суток.

Намедни попробовал настроить ограничение трафика для пользователей ftp на своем сервере, а то когда качают, невозможно работать. Долго изучал Linux Advanced Routing & Traffic Control HOWTO, в результате пришел к следующему:

# tc qdisc add dev eth1 root handle 1: prio //добавляем на интерфейс eth1 корневую qdisc PRIO

# tc qdisc add dev eth1 parent 1:1 handle 10: sfq perturb 2 limit 10000 //на первый канал PRIO вешаем qdisc sfq

# tc qdisc add dev eth1 parent 1:2 handle 20: tbf rate 10mbit buffer 16000 limit 32000 //на второй канал PRIO вешаем qdisc tbf с ограничением скорости 10мбит/сек

# tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip sport 20 0xffff flowid 1:2 //данные от ftp-сервера через второй канал PRIO

# tc filter add dev eth1 protocol ip parent 1: prio 2 u32 match ip protocol 0 0xff flowid 1:1 // все осталное через первый канал PRIO (protocol 0 - любой ip протокол)

Вообще-то правило по умолчанию выглядит в вышеуполянутом HOWTO несколько иначе:

# tc filter add dev eth0 protocol ip parent 1: prio 2 flowid 1:1

Но у меня (ASPLinux 9.2) на эту строчку система реагирует так:

Unknown filter "flowid", hence option "1:1" is unparsable

Ну ладно, FTP-трафик я этим ограничил, но также вместе с ним еще ограничил и все остальное до тех же 10мбит/сек. Проверял, скачивая данные из папок Samba с того же сервера. Никак не пойму, где я напарил.

Да, и еще кто-нибудь может подсказать, где можно найти нормальное подробное описание всех возможностей и параметров утилиты tc? Во встроенных в систему мануалах (декабрь 2001) почти ничего нет.

Доброго всем времени суток.

Имеется следующая система: роутер под Linux, он же интернет-шлюз, на интерфейсах eth0 и eth1 у него висят локальные сети 192.168.2.0/24 и 192.168.3.0/24 соответствено, форвардинг между ними в iptables разрешен.

iptables -A FORWARD -s 192.168.2.0/24 -d 192.168.3.0/24 -j ACCEPT

iptables -A FORWARD -s 192.168.3.0/24 -d 192.168.2.0/24 -j ACCEPT

Возникла задача обеспечить возможность пользователям подсетей играть друг с другом в сетевые игры. Но если кто-то из одной подсети создает игру, в другой подсети его не видят. В ходе изучения проблемы стало ясно, что большинство игр ищут сервер в локальной сети с помощью широковещательного запроса на адрес 255.255.255.255 на какой либо специфический порт (например 6125). Отсюда и вопрос - как разрешить форвардинг таких широковещательных пакетов по определенным портам?