====quote====
ahvel пишет:
====quote====
etc пишет:
Батарейки проверить в батарейном ящике.
=============
TIR2 чистое питание 2N+1 и ДГУ....
=============
Как будто это гарантирует спасение от нечаянного отключения шнура от этого чистого питания во время поиска методом отключения - "Что же тут у нас подключено?" ИЛИ пропадания внешнего питания во время профилактики чистого питания.
Производитель (Алкатель) настоятельно рекомендует использовать батарейные блоки. Радуйтесь, что у вас плата GD. GD-3 после некорректного отключения питания часто перестают запускаться. Отправлять приходится по гарантии поставщику.
25.09.2014 00:26:34, etc.]]>
====quote====
etc пишет:
Батарейки проверить в батарейном ящике.
=============
TIR2 чистое питание 2N+1 и ДГУ....
24.09.2014 20:27:30, ahvel.]]>
Батарейки проверить в батарейном ящике.
24.09.2014 19:01:34, etc.]]>
====quote====
error пишет:
lanpbxbuild что показывает?
=============
01. IP download: 172.27.0.27 IP CPU 1: 172.27.0.27 (это реальный адрес проца, main - 0.28)
на других станциях в сети смотрел, там вообще нет никаких данных и работает нормально
(11)xa000011> lanpbxbuild
No previous lanpbx.cfg file.
1. View
2. Add
3. Delete
4. Modify
5. Move
6. Apply changes
0. Quit
==> 1
Sorry, no entry.
====quote====
error пишет:
GD перезаливали?
=============
перезалил, бэд блоков на флеше 1
раз 5 перегружалась не могла скачать, потом скачала и заработала....
спасибо за участие, может что посоветуете дабы избежать в дальнейшем возможных глюков?
24.09.2014 11:25:12, ahvel.]]>
lanpbxbuild что показывает?
GD перезаливали?
23.09.2014 17:47:06, error.]]>
добрый день.
сегодня появилась похожая проблема.
OXE R5.1.2 MG
GD2 перестала запускаться:
/usr/bin/download_binary: CALLSERVER variable not set in /etc/config/local/ifcfg-eth0 !
/usr/bin/binmg_download: download_binary binmg failed
параметры IP в норме, все друг друга пингуют. подключены через минисвич на CPU, инцидентов на процессоре нет.
было сделано:
1. подозревали что винт на CPU посыпался, заменили новым, залили базу - то же самое
2. создал чистую базу, залил OPS, прописал МАС адрес GD - так же не может скачать
3. проверил порты, tftp не слушает...
[root@xa000010 mtcl]# netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:shell *:* LISTEN
tcp 0 0 *:servobs *:* LISTEN
tcp 0 0 *:netaccess *:* LISTEN
tcp 0 0 *:cmisd *:* LISTEN
tcp 0 0 loopback:netadmin *:* LISTEN
tcp 0 0 *:builddistant *:* LISTEN
tcp 0 0 *:loaddistant *:* LISTEN
tcp 0 0 *:www *:* LISTEN
tcp 0 0 *:suprout *:* LISTEN
tcp 0 0 *:ftp *:* LISTEN
tcp 0 0 *:telnet *:* LISTEN
tcp 0 0 *:rcsta *:* LISTEN
tcp 0 0 loopback:10005 loopback:cmisd ESTABLISHED
tcp 0 136 xa000010:telnet 10.185.120.52:49284 ESTABLISHED
tcp 0 0 loopback:cmisd loopback:10005 ESTABLISHED
udp 0 0 xa000010:32640 *:*
udp 0 0 *:tftp *:*
udp 0 0 x000010_tun:ntp *:*
udp 0 0 xm000010:ntp *:*
udp 0 0 loopback:ntp *:*
udp 0 0 *:ntp *:*
udp 0 0 *:hybrid-vpn *:*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 10 [ ] DGRAM 719 /dev/log
unix 2 [ ] DGRAM 9708
unix 2 [ ] DGRAM 4725
unix 2 [ ] DGRAM 2733
unix 2 [ ] DGRAM 1520
unix 2 [ ] DGRAM 1218
unix 2 [ ] DGRAM 1087
unix 2 [ ] DGRAM 839
unix 2 [ ] DGRAM 832
unix 2 [ ] STREAM CONNECTED 333
23.09.2014 14:24:15, ahvel.]]>
перезалайте софт на атс
на крайний случай можно не виртуалке поднять AS и MR3 привязать
15.05.2014 19:19:50, error.]]>
возможно, обязательно это выясним, когда найдем еще одну АТСку и запустим на ней старую систему
спасибо за помощь, о результатах отпишусь
15.05.2014 19:17:58, Михаил.]]>
Значить - чего-то забылось по дороге.
По идее:
- поменяли IP адреса на процессоре;
- поправили lanpbxbuild;
- на GD поправили IP параметры (mgconfig).
Рестартовали - и должно быть счастье.
15.05.2014 17:44:05, vad.]]>
====quote====
vad пишет:
Если вы меняли IP параметры - то в lanpbx оно само не поменяется.
Второе - после смены параметров через lanpbxbuild - мне помнится, что параметры в tftp демоне на лету не поменяются - требуется рестарт станции.
=============
После смены параметров через lanpbxbuild и рестарта станции она не поднялась. Дальше времени экспериментировать уже, к сожалению, не было.
15.05.2014 17:13:51, Михаил.]]>
====quote====
Dmitry Ryzhakov пишет:
Вы то пишете, что релиз 8 работал и перестал, то в конце - вводите новую станцию - речь шла об одной и той же АТС?
=============
Да, станция одна. Была станция, стояла себе спокойно несколько лет, ее никто не трогал, в один прекрасный воскресный день она частично перестала работать, после удаленной перезагрузки перестало работать все.
Далее три дня ковыряния привели только к тому, что АТС поднималась вручную, поэтому было принято решение взять новый жесткий диск и залить на него 8й релиз с патчем и далее базу и лицензии с этой глючной станции. А старый диск оставили для дальнейших разбирательств, когда появится подопытная АТС. После заливки все поднялось, поэтому поставили ее на прежнее место.
15.05.2014 17:11:50, Михаил.]]>
Если вы меняли IP параметры - то в lanpbx оно само не поменяется.
Второе - после смены параметров через lanpbxbuild - мне помнится, что параметры в tftp демоне на лету не поменяются - требуется рестарт станции.
15.05.2014 15:08:10, vad.]]>
сильно похоже, что на станции сперва что-то где-то работало, потом сменили IP адреса, но как водится не везде или не в нужном порядке. думаю, если вы на старом ПО сделаете полноценный netadmin, затем lanpbxbuild затем mgconfig на GD у вас все нормально стартует.
Вы то пишете, что релиз 8 работал и перестал, то в конце - вводите новую станцию - речь шла об одной и той же АТС?
15.05.2014 13:35:23, Dmitry Ryzhakov.]]>
lanpbxbuild при просмотре параметров показал адрес процессора и tftp сервера отличный от требуемого, т.е. если наш находится в хх.хх.111.хх сети, то там почему-то был задан хх.хх.11.хх вот такой адрес, но после внесения изменений и перезагрузки станции ситуация не поменялась:
Downloading /DHS3bin/downbin/emg/binmg from хх.хх.111.хх
/usr/bin/binmg_download: download_binary binmg failed
/usr/bin/binmg_download: too many retries, giving up
binmg download failed after 3 retries
ну и ничего не поднялось.
В итоге, потому как тянуть с вводом АТС уже нельзя, взяли другой жесткий диск, на него накатили через pc-installer систему, восстановили базу и лицензию и включили АТС, все заработало. Старый диск оставили, чтобы потом собрать тестовую станцию и на ней эту проблему до конца вылечить.
15.05.2014 12:55:35, Михаил.]]>
список netstat похож на нормальный, не понятно только почему tftp два раза... есть еще вариант потери файла lanpbx.cfg. восстановить его содержимое просто командой lanpbxbuild и далее заполнить нужные строчки, после - сохранить. подробнее - в доке.
15.05.2014 09:55:38, Dmitry Ryzhakov.]]>
(1)ygl_27> netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 *:shell *:* LISTEN
tcp 0 0 *:nmccs *:* LISTEN
tcp 0 0 *:servobs *:* LISTEN
tcp 0 0 *:netaccess *:* LISTEN
tcp 0 0 *:cmisd *:* LISTEN
tcp 0 0 127.0.0.1:netadmin *:* LISTEN
tcp 0 0 *:builddistant *:* LISTEN
tcp 0 0 *:loaddistant *:* LISTEN
tcp 0 0 *:www *:* LISTEN
tcp 0 0 *:suprout *:* LISTEN
tcp 0 0 *:ftp *:* LISTEN
tcp 0 0 *:telnet *:* LISTEN
tcp 0 0 *:rcsta *:* LISTEN
tcp 0 0 *:https *:* LISTEN
tcp 0 0 127.0.0.1:10001 127.0.0.1:cmisd ESTABLISHED
tcp 0 0 127.0.0.1:10002 127.0.0.1:10003 ESTABLISHED
tcp 0 0 127.0.0.1:10003 127.0.0.1:10002 ESTABLISHED
tcp 0 0 127.0.0.1:cmisd 127.0.0.1:10001 ESTABLISHED
udp 0 0 yglish_27:32640 *:*
udp 0 0 *:syslog *:*
udp 0 0 127.0.0.1:dhcdupli_m *:*
udp 0 0 *:prslink *:*
udp 0 0 *:incid2trap *:*
udp 0 0 *:9743 *:*
udp 0 0 *:snmp *:*
udp 0 0 *:bootps *:*
udp 0 0 *:bootps *:*
udp 0 0 *:tftp *:*
udp 0 0 *:tftp *:*
udp 0 0 yglish_27:ntp *:*
udp 0 0 127.0.0.1:ntp *:*
udp 0 0 *:ntp *:*
udp 0 0 *:hybrid-vpn *:*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 12 [ ] DGRAM 1358 /dev/log
unix 2 [ ] DGRAM 12687
unix 2 [ ] DGRAM 12659
unix 2 [ ] DGRAM 9196
unix 2 [ ] DGRAM 9166
unix 2 [ ] DGRAM 5048
unix 2 [ ] DGRAM 5044
unix 2 [ ] DGRAM 2453
unix 2 [ ] DGRAM 1957
unix 2 [ ] DGRAM 1500
unix 2 [ ] DGRAM 1491
unix 2 [ ] STREAM CONNECTED 677
Стартует GD статикой, сетевые настройки видно, все стоит как нужно.
14.05.2014 11:09:25, Михаил.]]>
какими-то вы хитрыми путями идете... на работающем CS дайте команду netstat -a - слушает ли он tftp порт?
в каком режиме стартует у вас GD - статический адрес или динамический? если статический - в процессе загрузки мелькает настройка GD - адрес, нетмаска, откуда грузится, номер полки и т.п. - эти настройки у вас не слетели? (смотреть в консольном порту GD)
13.05.2014 16:36:07, Dmitry Ryzhakov.]]>
Жесткий диск проверили, битых секторов нет, логические ошибки были, e2fsck их исправил, далее процессор грузится без проблем. Заходим на GD консолью, смотрим что пишет при загрузке, опять видим, что не может стянуть файл binmg с CS по tftp.
binmg : this is Media Gateway Software R8.0 for E-MGD version 43.15.2 built on 28 May 08 17 hours 17 min for r_mg_appli_43.15.2
Downloading /DHS3bin/downbin/emg/binmg from хх.хх.хх.хх
/usr/bin/binmg_download: download_binary binmg failed
Причем по ftp с GD на CS доступ есть, сетка в порядке. По TFTP доступа нет.
Смотрю на CS через PS -A |grep ftp - ответ пустой, значит tftp нет. Смотрю аналогично на другой АТС, пишет что данный сервис есть. Делаем вывод, что он не грузится на CS.
Запускаем его на CS ручками под рутом - /DHS3bin/servers/tftpd
далее запускаем с GD команду под рутом '/usr/bin/download_binary binmg'- все проходит на ура и файл появляется в /tmp/ с размером 990 байт - все как положено.
Осталось выяснить почему tftp сервер не грузится демоном при запуске CS.
Выясняем что грузится он через xinetd.
Смотрим конфиг /etc/xintetd.d/tftp и видим, что там он выключен, т.е. disable=yes, принудительно меняю через vi его на no, перегружаю, смотрю, он опять стоит в yes, т.е. отключен.
куда копать дальше?
13.05.2014 14:04:04, Михаил.]]>
Вначале у нас перестала работать внешняя связь, по IP-каналу. Внутренняя работала. После проверки решили перезагрузить станцию, тут всё и получили.
Проблемы с сетью пока исключаем, т.к. оба ЛАН-интерфейса (CS и DG2) включены в свич платы CS. От локалки отключили. Все платы на станции - out of service, кроме CS. Завтра проверим жесткий диск и подготовим тестовую подмену GD.
Может дело в жестком, файл бинарника посмотрели, по размеру и виду аналогичен подобному на другой станции. Командами линукса копируется и перезаписывается без проблем, а GD его никак не может взять.
13.05.2014 01:23:25, Михаил.]]>
вариантов много
1-ый
====quote====
Михаил пишет:
На станции етот файл есть.
=============
не факт, тобишь может только название от файла есть
смотрите smartctrl
2-ой
плате GD - кранты
надо вставать консолью на GD и смотреть тараканов
если другие GD загружаются значит действительно кранты, либо на половину
3-ый
IP-адреса совпадают с кем-то
arp -a
по IP от GD должен показать 00:80:хх:хх:хх:хх
и т.д. так далее по остальным вариантам
12.05.2014 18:08:25, error.]]>
Да, нужен МАС. Все остальное появится, когда плата прогрузится.
А с инцидентами на процессоре - что?
Изменения (работы) на сети были (в праздники что-то кто-то сделал)?
12.05.2014 18:07:56, vad.]]>
В менеджменте shelf/board/Ethernet param - есть МАС, но нет адреса, маски и шлюза, это так и должно быть?
12.05.2014 16:41:52, Михаил.]]>
Проверять IP параметры. Смотреть - что в менеджменте shelf/board/Ethernet param - указан МАС адрес GD. Смотреть инциденты на процессоре. Смотреть - как у вас сеть организована (может чего-то из протоколов на сети прикрыли).
12.05.2014 15:25:10, vad.]]>
Доброго времени! подскажите, станция R8, вдруг пропала внешняя связь по IP, перезагрузили и видим, что шлюз GD2 не загрузился. Пишет: Downloading/DHS3bin/downbin/....failed.
На станции етот файл есть. Проверку БД сделали. Сам шлюз пингуется, параметры IP норм.
Куда копать?
12.05.2014 14:53:48, Михаил.]]>