old
-
Публикации
17 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем old
-
-
Решил почитать на ночь код и заметил следующий кусок:
#this keeps the program alive or something after exec'ing perl scripts END() { } BEGIN() { } {no warnings; *CORE::GLOBAL::exit = sub { die "fakeexit\nrc=".shift()."\n"; }; }; eval q{exit}; if ($@) { exit unless $@ =~ /^fakeexit/; };Вообще-то это что-то связанное с FastCGI ( к примеру, см. Perl + FastCGI + nginx , "Пример с codemongers.com"), а данном контексте оно что делает? Глобально переопределяет "exit"? Но тогда, если верить доке , переопределение должно быть сделано внутри блока BEGIN. Я попробовал потестировать это кусок кода, но в текущем виде не заметил от него никакой реакции. Кто-нибудь может подсказать, зачем он нужен в этом демоне?
-
Некоторые модели свитчей D-Link имеют возможность управления с помощью фирменной программы SmartConsole, которая использует некий проприетарный протокол, в котором, в том числе, предусмотрена возможность отправки управляемым устройством trap'ов, ничего общего с SNMPшными не имеющими и стандартными средствами, рассчитанными на SNMP, не обрабатываемыми. Т.к. оказалось, что как минимум серия DES-1100 ничего кроме этих trap'ов слать не умеет (там нет поддержки ни SNMP, ни даже syslog), то пришлось реализовать их прием и обработку (запись в syslog), благо формат сообщений оказался весьма простым. Если кто-то заинтересовался, то исходный код лежит здесь. Писалось и работает под FreeBSD 8 и 9, под Linux обеспечена сборка, но, к сожалению, не тестировалось.
Что бы это все работало, в свитче надо включить отсылку trap'ов, причем IP адрес целевой машины должен быть внутри сети, которой принадлежит IP интерфейса свитча (наступил на эти грабли с DES-1100, у других моделей может быть по-другому).
-
Добрый день.
Какая серия коммутаторов ZTE поддерживает балансировку по IP при объединении портов LACP'ом?
-
Подобный костыль-то я реализовал с самого начала, что бы убедиться в решаемости проблемы. Но хотелось бы разобраться глубже, потому что как показало прицельное гугление, я не первый, кто на эти грабли наступил, вот к примеру топик в этом же разделе с другим вариантом костыль-решения, весьма аккуратным, надо заметить.
В качестве костыль-решения могу посоветовать в мпд5 прописать скрипт на поднятие интерфейсов и в него эту команду.Клиентский IP с такого интерфейса почему-то либо не анонсится вообще, либо вместо него анонсится IP с нашего конца туннеля, причем не взирая на route-map или distribution list. После очистки конфига интерфейса ng ("no ip ospf network") все работает нормально до следующего ребута. -
Настраивая ospfd из quagg'и, обнаружил, что в последней версии из портов (quagga-0.99.17_3) он не работает в 7.3-RELEASE-p*, выдавая ошибку
при этом в "ifmcstat -i vlan0" видно, что vlan0 не слушает multicast-группу 224.0.0.5. В тоже время на 8.1-RELEASE-p* все работает без проблем.sendmsg in ospf_write failed to 224.0.0.5, id 0, off 0, len 80, interface vlan0, mtu 1500: Permission deniedГугление привело к закрытому PR. После того, как откатил назад патч, закрывающий этот PR (что бы не заморачиваться с portdowngrade, просто удалил net/quagga/files/patch-lib-sockopt.c) и пересобрал quagga, все заработало. На тех машинах с 7.3-RELEASE-p*, где стояла quagga-0.99.17, собранная до сентября (время закрытия PR), все заработало сразу без танцев с откатом патча.
Похоже, в портах поломанная quagga (для случая FreeBSD 7.3), никто с подобным не сталкивался?
И немного про mpd 5.5 + quagga ospfd: когда mpd создает новые интерфейсы ng (скажем, после перезагрузки), в конфиге ospfd они появляются с прописанной на них командой
Клиентский IP с такого интерфейса почему-то либо не анонсится вообще, либо вместо него анонсится IP с нашего конца туннеля, причем не взирая на route-map или distribution list. После очистки конфига интерфейса ng ("no ip ospf network") все работает нормально до следующего ребута. "passive-interface default" в настройках ospf включено:ip ospf network broadcastrouter ospf ospf router-id 192.168.25.92 log-adjacency-changes detail compatible rfc1583 redistribute connected route-map STATIC-VPN passive-interface default no passive-interface vlan0 network 192.168.25.88/29 area 0.0.0.2 network 192.168.96.0/23 area 0.0.0.2 area 0.0.0.2 authentication message-digest area 0.0.0.2 stub ! access-list 10 permit 192.168.96.0 0.0.1.255 route-map STATIC-VPN permit 10 match ip address 10 !
Такое поведение вообще нормально или я что-то пропустил?
-
Как оказалось, патчить не обязательно. Достаточно запустить configure с опцией --host mips-linux, а не --host mips. И обязательно обратить внимание, что бы симлинки tap_dev.c и tun_dev.c смотрели на файлы в каталоге linux, а не generic. Как оказалось, configure, если видит, что они уже созданы, то не меняет их, даже если они неправильные. Полностью строка запуска configure выгдела вот так:
[skipped]Честно говоря, после долгих ковыряний у меня тоже ничего не получилось. Поэтому в последней версии прошивки он был удален. Попробую еще в модуле собрать - если получится, вернем обратно.
просто в config.h заменил строку
/* #undef HAVE_LINUX_IF_TUN_H */
./configure --host mips-linux --build=i686 --prefix="${APP_PATH}/vtun-3.0.0/filesystem" --disable-ssl --disable-lzo --disable-zlib
Тут еще проще, потому что configure поновее. Достаточно --host mips-linux, либо --host mips --target=mips-linux, а можно и все вместе:Кста, походу собрал openvpn, там при сборке похожие грабли, configure не детектит целевую систему и собирается без поддержки системного TUN/TAP. После принудительного #define TARGET_LINUX в config.h сборка происходит без проблем../configure --host mips-linux --build=i686 --target=mips-linux --prefix="${APP_PATH}/openvpn-2.0.9/filesystem" --disable-ssl --disable-lzo --disable-crypto --disable-debug --enable-small
-
Честно говоря, после долгих ковыряний у меня тоже ничего не получилось. Поэтому в последней версии прошивки он был удален. Попробую еще в модуле собрать - если получится, вернем обратно.
Ну вот и первая success story ;) При сборке vtun'а надо было заставить его собираться с системным TUN/TAP драйвером, а не со встроенным. Я не разбирался до конца, почему configure не задетектил системный драйвер (хотя у меня есть предположение, что это из-за того, что он вообще не понял, что целевая система linux), просто в config.h заменил строку
/* #undef HAVE_LINUX_IF_TUN_H */
на
#define HAVE_LINUX_IF_TUN_H
Да, и еще в mkimg в блок создания устройств в /dev надо дописать
mkdir $RW_ROOT/dev/net
mknod -m666 $RW_ROOT/dev/net/tun c 10 200
Кста, походу собрал openvpn, там при сборке похожие грабли, configure не детектит целевую систему и собирается без поддержки системного TUN/TAP. После принудительного #define TARGET_LINUX в config.h сборка происходит без проблем.
-
Кто-нибудь может поделиться success story про запуск vtun'а в Wive-0.6.0?
Потому что пытаюсь запустить его в режиме клиента, он запускается, поднимает соединение с удаленной стороной, после чего обваливается с руганью: "Can't allocate tap device tap1. No such file or directory(2)"
Смотрю в /dev - все правильно, нет такого устройства, гуглю, создаю его mknod /dev/tap1 c 10 200, получаю ругань:"File descriptor in bad state (81)". И так с любым устройством tun/tap. По опыту использования vtun/openvpn на других системах, это очень похоже на то, что в системе отсутствует драйвер tun/tap, но в выводе dmesg видно, что он таки в ядре еть.
У кого какие мысли есть по такому случаю?
Кста, пока обгугливал эту тему, нашел как минимум один схожий случай, когда драйвер не работал, будучи вкомпиленным в ядро, но все заработало в модульном варианте...
-
./rtl83xx_dlink_des1016d 52:54:4с:01:02:03@eth0 show running-config | grep igmp no ip igmp snooping
=((((
В чем может быть дело ?
1) c svn обновление взяли, rtl83xx_dlink_des1016d пересобрали?
там раньше было недописано сохранение настроек igmp snooping'а, я поправил
2) flash точно открылось на запись?
+ вопрос, чем отличается "reboot soft" от "reboot hard" ?при "reboot soft" перезапускаются только интерфейсы, сам чип не ребутится.
"reboot hard" аналогичен перезапуску по питанию.
-
"% Not implemented yet" означает что память не доступна на запись ?
Как записать настройки IGMP snooping в память ?
"% Not implemented yet" означает, что запись в EEPROM в rrcp_cli пока не реализована.
Сейчас запись работает только в rtl83xx, т.е. в вашем случае надо выполнить команду
./rtl83xx_dlink_des1016d 52:54:4с:01:02:03@eth0 write memory
Извините, поторопился.
Предварительно возьмите обновление с svn и пересоберите rtl83xx_dlink_des1016d.
-
"% Not implemented yet" означает что память не доступна на запись ?
Как записать настройки IGMP snooping в память ?
"% Not implemented yet" означает, что запись в EEPROM в rrcp_cli пока не реализована.
Сейчас запись работает только в rtl83xx, т.е. в вашем случае надо выполнить команду
./rtl83xx_dlink_des1016d 52:54:4с:01:02:03@eth0 write memory
-
Читал с интересом, идея о том, что проект Арпанет был американским ответом на наши разработки - наиболее позабавила. Должен признать, что вычислительный комплекс ЗРК С300 - это действительно довольно фантастическая штука, учитывая, что он разрабатывался в 60-х годах...
Скорее, арпанет был ответом на ОГАС, вот здесь это достаточно подробно описано:
-
RealTek - любую на rtl8139. Если в драйверах производителя платы нет поддержи VLAN, можно попробовать универсальные драйвера с www.realtek.com.tw
Intel - практически любую.
Или, как вариант, платы на rtl8169s, к примеру TP-Link TG-3269. На 100Mb/s оно работает без проблем,
в качестве бонуса умеет hardware tagging, хотя лично я это не проверял. Просто стоят они меньше $20.
-
Asus P5LD2-VM DH, не путать с просто P5LD2-VM.
4 SATA (умеют AHCI и 300MB/s трансфер) плюс 2 PATA/100 на ICH7R и 2 PATA/133 на ITE8211F для пущей радости. Onboard video и Intel 1Gb LAN, причем, что весьма ценно - PCI Express based.
ICH7R вообще-то умеет недоRAID, но не одновременно с AHCI, так что лучше сразу делать софтовый RAID.
Для нормальной работы надо отключить в BIOS'е "Intel Quick Resume", в остальном этими материнками доволен. Использую FreeBSD 6.1-STABLE, но делал и сервер с Linux (kernel 2.6.17.11, 2.4.х не видят LAN).
-
Всем добрый день/вечер.
Возникла задача оконечить оптику, со стороны провайдера включенную в свитч имени Nortel'а. Порт 100Мб/с, не WDM. Мы обычно используем WDM, так что проверить методом научного тыка, какой медиаконвертер подойдет, я не могу. Может кто поделится опытом, а то Nortel в наших краях зверь редкий, непуганный :)
Просто провайдер вспомнил о том, что у него на точке включения, куда подведена наша оптика, нет обычных fastethernet портов в последний момент, когда я уже договаривался везти к ним наш конвертер ;(
-
Может у когото есть ещё какие нибудь предложения?
Реле на 12 или 5 вольт к соответсвующим выводам БП, нормально _замкнутые_ контакты - параллельно кнопке power.
DHCP server with SQL support on Perl
в Программное обеспечение, биллинг и *unix системы
Опубликовано · Жалоба на ответ
Походу да, потому что именно под FastCGI exit() делать нельзя и приходится выкручиваться, переопределением в том числе. Вот тут пример граблей, если вдруг кому интересно...