После гарантийной замены платы CS-2 обнаружил что нет доступа по FTP, ни под mtcl, ни под adfexc - сначала выходит приглашение логина, потом пароля, после чего сообщает что логин неверный. Собственно говоря, возможно этот доступ пропал и до того как плату передали в гарантийку (жесткий диск, планка памяти, дочерние платы остались прежние). Сетевые проблемы исключались - подключался ноутбуком напрямую к коммутатору на CS-2, также заходил на станцию по телнету, и уже там пробовал подключатся по FTP: (117)a> ftp 10.10.20.34 Connected to a. 220 a FTP server () ready. Name (10.10.20.34:mtcl): mtcl 331 Password required for mtcl. Password: 530 Login incorrect. ftp: Login failed. ftp> bye 221 Goodbye. (117)a>
После долгих проверок всяких параметров (включая Security в netadmin) и т.п., обнаружил что файл /etc/ftpaccess выглядит так: [root@a mtcl]# cat /etc/ftpaccess passive ports 0.0.0.0/0 10000 10499
А на остальных станциях, где доступ по FTP есть, файл выглядит так: (106)d> cat /etc/ftpaccess class all real,guest,anonymous *
email root@localhost
loginfails 5
readme README* login readme README* cwd=*
message /welcome.msg login message .message cwd=*
compress yes all tar yes all chmod no guest,anonymous delete no guest,anonymous overwrite no guest,anonymous rename no guest,anonymous
Зашел под рутом и с помощью редактора vi подправил файл /etc/ftpaccess, сделав его как на остальных АТС. После этого еще нашел что можно было этот файл слить с рабочей АТС, и через гипертерминал передать на проблемную АТС - описано здесь: http://www.alcatelunleashed.com/viewtopic.php?f=222&t=16999 Но поскольку работы по замене платы процессора делались на выезде, а проблемы с FTP решались уже из головного офиса по сети, мне больше подошел мой способ.
На всякий случай проверил количество файлов в /etc/ и их размеры - количество совпадает с количеством на нормально работающих АТС, размеры отличаются в hosts (что логично) и eth_redund.conf - на проблемной АТС он пустой, на других он такой: cat /etc/eth_redund.conf # this file is used to configure module options # for the bonding module. It is used by netadmin # and mk_routes. # do not edit it by hand miimon=100 mode=1
Собственно говоря проблема вроде решена, и возможно кому-то поможет в будущем, но меня больше беспокоит вопрос от чего это могло произойти, и не придется ли править этот файл после следующей перезагрузки? Также непонятно на что влияет /etc/eth_redund.conf - файл явно связан с Алкатель, а не с Linux как таковым (в обычном Linux я такого файла не знаю).
Добрый день. ОХЕ R9.1, звонки из города прилетают с PRI-потока, кому какой номер отдавать разрулено через DID. На внутренний номер 1111 приходит городской номер 7654321. Хотелка такая - если абонент 1111 занят, или не отвечает на звонок с города, пересылать такие звонки на хантинг группу 6000 с паралельным типом искания (в группе три абонента). Акцент на том, что перенаправлять нужно только внешние звонки - т.е. "Overflov busy to associated set" на номер хантинг группы не подходит - он посылает туда и внутренних абонентов. Думал что можно создать еще одну хантинггруппу, где членами будут 1111 и группа 6000 - не дает, говорит только станции могут там быть. Есть какие-то идеи?
Помогите решить проблему. Есть ОХЕ, к которой подключено 5 PRI потоков. Настроен ARS, который распределяет куда звонок отправлять. С входящими внешними звонками все нормально - прилетает номер, абонент видит его на дисплее аппарата. С исходящими внешними звонками ситуация такая - набранный номер виден до тех пор, пока не произошло соединение с абонентом, потом на дисплее отображается название транкгруппы. Все это устраивало, пока не подключили систему записи голоса, которая берет информацию с CLI Data. - Стало неудобно анализировать звонки в отчетах системы записи. Можно как-то сделать, чтобы на дисплее и после соединения с удаленным абонентом отображался набранный номер? В идеале - не для всех абонентов АТС, а только для той части цифровых абонентов, к которым подключили систему записи голоса.