Элтекс

Device type: LTE-2X
Hardware revision: 1v2
Version: 3.14.2
Build: 183

После отправки SNMP запроса lte8stONTIDConfigBlocked.ONT_ID = 1, с некоторой вероятностью, близкой к 50%, абонент не блокируется, его трафик продолжает ходить, при этом проверка состояния lte8stONTIDConfigBlocked.ONT_ID возвращает результат "1" (блокировано).
Если после этого выполнить "reconfigure" через веб-интервейс, либо отправить по SNMP lte8stONTIDStateReconfigure.ONT_ID = 1 - абонент блокируется нормально.
Это баг прошивки, или так должно быть?

Отдельная просьба к админу - отправляйте запрос подтверждения регистрации с существующего и способного принять уведомление о результате доставки E-Mail адреса, так как сейчас вы нарушаете RFC-821/2821, спам-фильтры ваши письма блокируют.

# host -t mx vps.eltex.org
vps.eltex.org has no MX record
# host vps.eltex.org
vps.eltex.org has address 94.250.248.55
# nc -v 94.250.248.55 25
Connection to 94.250.248.55 25 port [tcp/smtp] succeeded!
220 eltex.org ESMTP Exim 4.80 Thu, 05 Mar 2015 10:35:13 +0300
ehlo planet.dn.ua
250-eltex.org Hello planet.dn.ua [193.39.72.1]
250-SIZE 52428800
250-8BITMIME
250-PIPELINING
250-AUTH PLAIN LOGIN CRAM-MD5
250-STARTTLS
250 HELP
mail from: <>
250 OK
rcpt to: <www-data@vps.eltex.org>
550 relay not permitted
quit
221 eltex.org closing connection

__Dimon__ писал(а):Отдельная просьба к админу - отправляйте запрос подтверждения регистрации с существующего и способного принять уведомление о результате доставки E-Mail адреса, так как сейчас вы нарушаете RFC-821/2821, спам-фильтры ваши письма блокируют.

На самом деле ящик может быть вполне себе noreply. И он собственно так и настроен: forum-noreply@eltex.nsk.ru. Если это не так, то пришлите заголовки полученного Вами письма.
Исходная задача доставить письмо с линком. Обратных писем посылать не надо, в том числе и подтверждений о прочтении. Это достаточно давно устоявшаяся технология.
Достаточно настроить спам-фильтры. Например, добавить сайт в белый список.

А к Вам у меня есть вопрос: зачем регистрируетесь под вымышленными именем и фамилией? Как-то тоже есть шанс не пройти через спам-фильтр.

Алексей Сергеев писал(а):Исходная задача доставить письмо с линком. Обратных писем посылать не надо, в том числе и подтверждений о прочтении. Это достаточно давно устоявшаяся технология.

Ряд фильтров, используют технологию проверки существования адреса отправителя, и способность принять уведомление. В случае непрохождения проверки, письмо будет отклонено, и ваша задача выполнена не будет.
Пример (ручной) такой проверки, я привел в первом сообщении, так же, можете посмотреть как работает реальный фильтр: http://www.wanlink.com/spamilter/faq/#w ... rification
Вымышленное имя..., уж извините, но я не привык оставлять свои личные данные в интернете, по крайней мере без крайней необходимости.

По ходу ковыряния с SNMP, возникла еще пара вопросов:
lte8stONTIDStatReceivePONFCSErrors
lte8stONTIDStatReceivePONCRC8Errors
lte8stONTIDStatReceivePONLineCodeErrors
lte8stONTIDStatReceivePONLaserPower
lte8stONTIDStatTransmitPONLaserPower
lte8stONTIDStatTransmitPONLaserTemp

1. Все эти значения равны нулю, при двух десятках активных абонентов, и аптайме 93,5 часа.
lte8stONTIDPONFecUp и lte8stONTIDPONFecDown у всех "false", хотя в веб-конфигураторе "Configuration / OLT 0 / Ports" опции "Upstream FEC" и "Downstream FEC" включены.
Все это просто не доделано?
2. Нет симметричных счетчиков ошибок в сторону абонента.

Стоит ждать чего то в следующей прошивке, или можно забыть?
В идеале, нужно знать затухание, и SNR (хотя бы "margin") либо ошибки, в обе стороны, для выявления проблем с физикой и оптической частью оборудования.

__Dimon__ писал(а):По ходу ковыряния с SNMP, возникла еще пара вопросов:
lte8stONTIDStatReceivePONFCSErrors
lte8stONTIDStatReceivePONCRC8Errors
lte8stONTIDStatReceivePONLineCodeErrors


1. Все эти значения равны нулю, при двух десятках активных абонентов, и аптайме 93,5 часа.
lte8stONTIDPONFecUp и lte8stONTIDPONFecDown у всех "false", хотя в веб-конфигураторе "Configuration / OLT 0 / Ports" опции "Upstream FEC" и "Downstream FEC" включены.

Добрый день!
По данным SNMP запросам действительно есть недоработки. Будет исправлено в будущих версиях, по сроках пока сориентировать не могу.

__Dimon__ писал(а):По ходу ковыряния с SNMP, возникла еще пара вопросов:
lte8stONTIDStatReceivePONLaserPower
lte8stONTIDStatTransmitPONLaserPower
lte8stONTIDStatTransmitPONLaserTemp

Вы хотите узнать значение RSSI вводя данные запросы?

Скорее "оценить", догадываюсь, что мощность лазера выбирается автоматически, исходя из текущего затухания.
Пока снимаю lte8stONTIDStateLaserPowerdBm / 10, по опыту: идеальные значения в районе -20, проблемы начинаются при -30.
Непосредственно в SFP включен разветвитель на 4, через 1...1,5км разветвители на 8 или 16, плюс еще до 200м до абонентов.

Еще один неприятный момент...
Если абонентский терминал в данный момент выключен, запросы c его ONT ID возвращают ошибку "No Such Instance", из за чего нельзя считать показания счетчиков трафика
lte8stONTIDStatReceivePONBytes
lte8stONTIDStatTransmitPONBytes
В итоге, теряется информация о трафике, с момента ее последнего успешного снятия, до момента отключения терминала.

__Dimon__ писал(а):
Если абонентский терминал в данный момент выключен, запросы c его ONT ID возвращают ошибку "No Such Instance", из за чего нельзя считать показания счетчиков трафика
lte8stONTIDStatReceivePONBytes
lte8stONTIDStatTransmitPONBytes
В итоге, теряется информация о трафике, с момента ее последнего успешного снятия, до момента отключения терминала.

Данная проблема будет решена в следующей версии (по срокам пока не сориентирую).

Обнаружился баг в snmp демоне LTE-2X.
Если посылать lte8stONTIDStateReconfigure.ONT_ID = 1
с не существующим или неактивным ONT_ID, то устройство на этот запрос не отвечает,

# snmpset -v 2c -c private 192.168.xxx.xxx 1.3.6.1.4.1.35265.1.21.6.10.1.10.0.9999 u 1
Timeout: No Response from 192.168.xxx.xxx

Но через несколько секунд, с него прилетает трап ColdStart,
и в логе, доступном через веб-интерфейс, появляется запись:

Mar 25 14:12:09 LTE-2X snmp_wd: SNMPD is not responding! Restarting it!

Что бы обрушить демона, нужно знать WriteCommunity, так что, для DDOS это не подходит, но все же неприятно.

После обновления на:
Version: 3.16.1
Build: 3
обнаружилась проблема.

set lte8stONTIDConfigBlocked = 0
set lte8stONTIDStateReconfigure = 1

Reconfigure в этом случае молча игнорируется, на протяжении первых нескольких десятков секунд, после установки Blocked из "1" в "0".
get lte8stONTIDConfigBlocked возвращает "0", но в веб-морде абонент в состоянии "BLOCKED" и трафик не ходит.
Проблема присутствует не зависимо от того, отправлялись эти два запроса в пределах одной PDU, или двумя разными.
Фактически пока работает только с таким вот костылем:

# snmpset -c private -v 2c 192.168.xxx.xxx 1.3.6.1.4.1.35265.1.21.16.2.1.19.255.1007 i 0
# sleep 60
# snmpset -c private -v 2c 192.168.xxx.xxx 1.3.6.1.4.1.35265.1.21.6.10.1.10.0.1007 u 1

Добрый день.
Приложите лог с LTE с повторением проблемы, укажите pon_mac ONT.

Все странным образом заработало как раньше. Возможно, необходимо еще какое то условие. Если обнаружу - отпишусь.
Пока насторожило двойное удаление и добавление ONT (первые 4 строчки обоих блоков):



Есть еще одна проблема (присутствовала и в прошивках ветки 3.14):
NTE-RG-1402G-W:rev.B
Firmware revision: E1.15
находясь в состоянии BLOCKED, каждые 15 минут "отваливаются" (по watchdog ?),
LTE шлет трапы LinkDown/LinkUp, и пишет в логи следующее:



С NTE-2 и NTE-RG-1402G подобного пока не замечено.