После гарантийной замены платы 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

log transfers anonymous,real inbound,outbound

shutdown /etc/shutmsg

passwd-check rfc822 warn
passive ports   0.0.0.0/0       10000   10499
(106)d>

Зашел под рутом и с помощью редактора 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 я такого файла не знаю).