iface delta errors что означает

Шпаргалка по настройке сети в Linux

Что за компьютер без подключения к сети и к Интернету, в частности? Данная шпаргалка поможет настроить сетевые интерфейсы в Линуксе, а для примера будет взят Debian.

И так, в самом начале необходимо удостовериться, что ваша сетевая карта в компьютере обнаружена ОС, для этого выполним команду:

Как видно из приведенного примера, в компьютере установлена сетевая карта от nVidia c драйвером 0.64 и с присвоенным интерфейсом под названием eth0, правда, он в данный момент не активен, т.к. отсутствует соединение кабеля к сетевой плате.

Теперь можно ввести в консоль следующую команду для отображения информации о сетевых интерфейсах:

На что она нам покажет:

eth0 Link encap:Ethernet HWaddr 00:1d:60:47:8f:78
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:42 Base address:0xa000

lo Link encap:Локальная петля (Loopback)
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:122 errors:0 dropped:0 overruns:0 frame:0
TX packets:122 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12867 (12.8 KB) TX bytes:12867 (12.8 KB)

Первый интерфейс – это eth0, с MAC-адресом 00:1d:60:47:8f:78. Т.к. в описании интерфейса отсутствует слово RUNNING, то это означает, что сетевой кабель не подключен. Второй интерфейс, присутствующий в списке – это lo, локальный интерфейс (т.н. называемый Loopback), который имеет фиксированный для всех loopback-интерфейсов IP-адрес 127.0.0.1, маску подсети 255.0.0.0 и статус RUNNING. Из всего приведенного видно, что сетевой интерфейс eth0, который нам нужен для организации сети и выхода в Интернет, не настроен. Сейчас мы этим и займемся.

Нам необходимо отредактировать файл конфигурации /etc/init.d/networking, но в Debian’e его нельзя редактировать до тех пор, пока не остановлены сетевые интерфейсы. Поэтому нужно отключить интерфейс:

Однако, у нас же еще интерфейс eth0 не сконфигурирован, поэтому мы получим сообщение об ошибке: ifdown: interface eth0 not configured. Тогда, для начала, проверяем существование файла /etc/network/interfaces. Если он не существует, то создадим его, а если существует, то отредактируем:

На экран консоли должно вывестись примерно следующее:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
#iface eth0 inet dhcp

Если у вас есть маршрутизатор с включенной функцией DHCP (т.е. происходит автоматическая раздача IP-адресов для подключающихся устройств), то достаточно в конфигурационном файле разкомментировать строку #iface eth0 inet dhcp. В противном случае, необходимо привести файл конфигурации к следующему виду:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 8.8.8.8 8.8.4.4
#iface eth0 inet dhcp

Adress – это IP-адрес, который вы присваиваете сетевой карте на интерфейсе eth0, netmask – маска подсети, gateway – шлюз, dns-nameservers – адреса DNS-серверов. Теперь необходимо активировать сетевой интерфейс:

А также перезапустить сетевые службы:

Теперь можно заново запустить команду ifconfig и убедиться, что интерфейс eth0 настроен, т.е. присутствуют указанные нами сетевые настройки. Для проверки работоспособности, можно пропинговать шлюз или интернет-ресурс, если у вас есть выход в Интернет:

Должно быть выведено следующее:

PING yandex.ru (213.180.204.211) 56(84) bytes of data.
64 bytes from yandex.ru (213.180.204.211): icmp_req=1 ttl=50 time=15.1 ms
64 bytes from yandex.ru (213.180.204.211): icmp_req=2 ttl=50 time=14.1 ms
64 bytes from yandex.ru (213.180.204.211): icmp_req=3 ttl=50 time=14.3 ms
64 bytes from yandex.ru (213.180.204.211): icmp_req=4 ttl=50 time=13.8 ms
64 bytes from yandex.ru (213.180.204.211): icmp_req=5 ttl=50 time=13.9 ms

На этом настройка сети в Линуксе завершена.

Источник

Коды ошибок частотного преобразователя Delta

Частотные преобразователи относятся к сложной промышленной электронике достаточно дорогой и в тоже время широко распространенной по всему миру. На сегодняшний день трудно себе даже представить какое-либо производство, на котором бы не работало данное промышленное оборудование.

К сожалению, в процессе эксплуатации выходит из строя даже самое надежное промышленное оборудование. В данной статье мы разберем частотный преобразователь известного китайского производителя промышленной электроники и оборудования Delta, точнее коды ошибок частотного преобразователя Delta серии VFD-VE, с полной расшифровкой. Частотники в наше время нашли широкое применения в абсолютно всех сферах промышленности управляя как мини моторами в оргтехнике, так и гигантскими двигателями в горнодобывающей промышленности.

Для простоты общения со столь сложной электроникой все частотные преобразователи оснащены небольшими дисплеями с помощью которых выводятся информационные сообщения с кодами ошибок, расшифровав которые можно сразу же узнать причину ее возникновения. Если учесть распространенность данной промышленной электроники, то появляется острая нужда в расшифровке кодов ошибок частотных преобразователей.

Коды ошибок частотного преобразователя Delta серии VFD-VE и их расшифровка.

В таблицах ниже приведены все коды ошибок частотного преобразователя Delta серии VFD-VE и их расшифровка, то есть причина по которой возникла та или иная ошибка.

Внимание, для предотвращения повторной аварийной остановки оборудования, перед сбросом ошибки необходимо устранить причину сбоя и только после этого выполнись сброс кода ошибки частотного преобразователя Delta.

Коды ошибок частотного преобразователя Delta VFD-VE

Код ошибки

Описание ошибки

Возможное устранение

Превышение тока при разгоне.

Превышение тока при замедлении.

Превышение тока при установившейся работе.

Аппаратная неисправность при определении тока

Замыкание на землю.

К.З. в силовом модуле ПЧ

Обратитесь в сервисный центр.

Перенапряжение в процессе разгона.

Перенапряжение в процессе замедления

Перенапряжение при установившейся работе

Аппаратная неисправность определения перенапряжения

Низкое напряжение при разгоне

Низкое напряжение при замедлении

Низкое напряжение при установившейся скорости

Внутренняя память EEPROM не программируется

Техническое обслуживание частотных преобразователей Delta

Своевременное техническое обслуживание частотных преобразователей Delta, впрочем, как и любого другого производителя способствует значительному продлению срока безаварийной эксплуатации дорогостоящего промышленного оборудования. В таблице ниже приведены желательные сроки технического обслуживания частотных преобразователей Delta установленные производителем.

Периодичность технического обслуживания частотных преобразователей Delta

Проверка

Тип проверки

Способ проверки

Периодичность

Проверка температуры окружающей среды, влажности, механической вибрации, пыли, коррозийных и загрязняющих веществ, газов и жидкостей.

Визуальный осмотр, измерение параметров окружающей среды.

Присутствие любых опасных предметов или объектов.

Проверка напряжения питания на соответствии спецификации, проверка правильности подключения.

Измерение напряжение сети мультиметром.

Проверка индикации пульта.

Наличие непонятных символов, пропадания символов.

Проверка на наличие видимых повреждений, ненормальной вибрации и звуков.

Присутствие любых опасных предметов или объектов.

Проверка на наличие изменения цвета, перегрева.

Раз в шесть месяцев.

Присутствие посторонних частиц пыли и грязи.

Раз в шесть месяцев.

Проверка соединительных винтов, их наличие и качество затяжки.

Визуальный осмотр, при необходимости затянуть или заменить.

Раз в шесть месяцев.

Проверка соединительных проводов на качество изоляции, повреждения, изменения цвета или нагрева.

Раз в шесть месяцев.

Присутствие посторонних частиц пыли и грязи.

Раз в шесть месяцев.

Соединительные силовые клеммы.

Проверка клемм, их наличие, отсутствие деформации или перегрева.

Раз в шесть месяцев.

Проверка соединительных проводов на качество изоляции, повреждения, изменения цвета или нагрева.

Раз в шесть месяцев.

Наличие видимых повреждений.

Раз в шесть месяцев.

Проверка на наличие утечки жидкости, деформации корпуса, изменения цвета.

Измерение статической емкости конденсаторов.

Измеренная емкость > 8.85x

Раз в шесть месяцев.

Резисторы силовой части.

Проверка на наличие запаха, деформации корпуса, изменения цвета.

Раз в шесть месяцев.

Измерение значения сопротивления.

Измерение проводятся мультиметром между клеммами «+1/+2» и «-». Сопротивление должно быть в пределах + 10% от номинального значения.

Раз в шесть месяцев.

Трансформаторы и дроссели.

Проверка на наличие запаха, деформации корпуса, изменения цвета, вибрации при работе.

Раз в шесть месяцев.

Магнитные пускатели и реле.

Проверка на затяжки винтов клемм.

Проверка нагрева, подгорания.

Силовая печатная плата и силовой клеммник.

Проверка на затяжки винтом клемм и соединителей.

Раз в шесть месяцев.

Проверка нагрева, подгорания, изменение цвета и запаха.

Раз в шесть месяцев.

Наличие повреждений, сколов, следов коррозии.

Раз в шесть месяцев.

Изменение формы или повреждение конденсаторов, утечка электролита.

Раз в шесть месяцев.

Проверка на ненормальный шум и вибрацию.

Проверка затяжки винтов.

Визуальный осмотр, затяжка винтов.

Наличие повреждений, сколов, следов коррозии.

Проверка на наличие загрязнения, посторонних предметов, возможности свободного прохода воздуха.

Принципиальные электрические схемы подключения частотных преобразователей Delta

Сброс ошибок и Ремонт частотников в сервисном центре

Специалисты нашего сервисного центра уделяют максимальное внимание к качеству исполнения ремонта, программирования и настройке промышленного преобразователя частоты, не зависимо от производителя данного промышленного оборудования. Именно поэтому мы смело даем гарантию на все выполненные работы шесть месяцев.

Ремонт частотного преобразователя Delta производится исключительно с использованием оригинальных запасных частей, на компонентном уровне с применением высокотехнологичного оборудования, квалифицированным персоналом с инженерным образованием.

Если на вашем производстве появились проблемы с частотным преобразователем, которые вы не можете решить самостоятельно, мы всегда рады вам помочь. Обращайтесь в сервисный центр «Кернел». Специалисты нашей компании в минимальные сроки проведут глубокую диагностику и последующий ремонт частотного преобразователя. Оставьте заказ на ремонт оборудования используя форму на сайте, либо свяжетесь с нашими менеджерами, сделать это очень просто.

Как с нами связаться

У вас остались вопросы, связанные с ремонтом, программированием и настройкой частотных преобразователей или другого промышленного оборудования? Задайте их нашим менеджерам. Связаться с ними можно несколькими способами:

Далеко не полный список производителей промышленной электроники и оборудования, ремонтируемой в нашей компании.

Источник

Переводы страниц руководства

НАЗВАНИЕ

ОПИСАНИЕ

/etc/network/interfaces содержит информацию по настройке сетевого интерфейса для команд ifup(8) и ifdown(8). Здесь вы указываете, каким образом ваша система подключена к сети.

Строки, которые начинаются с символа ’#’, игнорируются. Обратите внимание, что комментарии с явным указанием конца строки НЕ поддерживаются, комментарии должны занимать одну строку.

Строка может быть перенесена на новую строку для удобства чтения, для этого в конце строки необходим символ «\».

Файл состоит из нуля или более строф «iface», «mapping», «auto» и «allow-«. Ниже приведён пример.

Строки, начинающиеся со слова «auto», используются для идентификации физических интерфейсов при их подьеме в время запуска ifup с опцией -a. (Эта опция используется сценариями загрузки системы.) Имена физических интерфейсов должны следовать за словом «auto» в той же строке. Может быть несколько строф «auto». ifup поднимет названные интерфейсы в порядке их перечисления.

Строфы, начинающиеся со слова «mapping», используются для определения, какой логический интерфейс соответствует физическому интерфейсу, который будет поднят. Первая строка строфы отображения (mapping) состоит из слова «mapping» с последующим шаблоном, соответствующим синтаксису глобальной оболочки. Каждая такая строфа отображения должна содержать определение сценария. Именованный сцеанрий запускается с именем физического интерфейса в качестве аргумента и с передачей на его стандартный вход всех следующих «map» строк (без ведущей «map») в строфе. Сценарий перед завершением должен вывести строку на стандартный вывод. Обратитесь к /usr/share/doc/ifupdown/examples за примерами того, что должен вывести сценарий.

Отображение имени состоит из поиска необходимого шаблона отображения и запуска сценария, соответствующего первому совпадению; сценарий выводит имя, в которое будет отображено исходное имя.

Строфы, определяющие логические интерфейсы, начинаются со строки, содержащей слово «iface», которая сопровождается именем логического интерфейса. В простых конфигурациях, без строф отображения, это имя просто должно быть именем физического интерфейса, к которому будут применены настройки. (Сценарий отображения по умолчанию действует подобно команде echo.) За именем интерфейса следует название семейства адресов, которое использует интерфейс. Это может быть «inet» для сетей TCP/IP, но имеется так же поддержка сетей IPX («ipx»), и сетей IPv6 («inet6»). За ним следует название метода, используемого для настройки интерфейса.

Дополнительные опции могут быть заданы в последующих строках строфы. Доступность опций зависит от семейства и метода, как описано ниже. Дополнительные опции могут предоставляться другими пакетами Debian. Например, пакет wireless-tools предоставляет несколько опций, начинающихся с «wireless-«, которые можно использовать для настройки интерфейса с помощью iwconfig(8). (Обратитесь к wireless(7) за подробностями.)

Опции обычно содержат отступ для ясности (как в примере выше) но это не обязательно.

ОПЦИИ IFACE

СЕМЕЙСТВО АДРЕСОВ INET

Этот раздел описывает методы, доступные для семейства адресов inet.

Метод loopback

Этот метод может использоваться для описания интерфейса обратной петли IPv4.

Метод static

Этот метод может использоваться для описания Ethernet-интерфейсов со статически выделенными IPv4 адресами.

Метод manual

Этот метод может использоваться для описания интерфейсов, для которых нет настроек применяемых по умолчанию. Такие интерфейсы могут настраиваться вручную, подразумеваемыми командами up и down, или сценариями из каталогов /etc/network/if-*.d.

Метод dhcp

Этот метод может использоваться для получения адреса через DHCP любым из перечисленных инструментов: dhclient, pump, udhcpc, dhcpcd. (Они были перечислены в порядке их приоритета.) Если у вас сложная конфигурация DHCP, вам следует знать, что некоторые из клиентов используют собственные настроечные файлы и не получают настроечную информацию посредством ifup.

Метод bootp

Метод может использоваться для получения адреса через bootp.

Метод ppp

Этот метод использует pon/poff для настройки интерфейса PPP. Обратитесь к этим командам за подробностями.

Метод wvdial

Этот метод использует wvdial для настройки интерфейса PPP. Обратитесь к этой команде за подробностями.

СЕМЕЙСТВО АДРЕСОВ IPX

Этот раздел описывает методы, доступные для семейства адресов ipx.

Метод static

Этот метод может использоваться для настройки интерфейса IPX. Он требует команду ipx_interface.

Метод dynamic

Этот метод может использоваться для динамической настройки интерфейса IPX.

СЕМЕЙСТВО АДРЕСОВ INET6

Этот раздел описывает методы, доступные для семейства адресов inet6.

Метод loopback

Этот метод может использоваться для описания интерфейса обратной петли IPv6.

Метод static

Этот метод может использоваться для описания интерфейсов со статически назначенными IPv6 адресами.

Метод manual

Этот метод может использоваться для описания интерфейсов, для которых нет настроек применяемых по умолчанию. Такие интерфейсы могут настраиваться вручную, подразумеваемыми командами up и down, или сценариями из каталогов /etc/network/if-*.d.

Метод v4tunnel

Этот метод может использоваться для настройки туннеля IPv6-over-IPv4. Для него необходима команда ip из пакета iproute.

ИЗВЕСТНЫЕ НЕИСПРАВНОСТИ/ОГРАНИЧЕНИЯ

ifup и ifdown работают с так называемыми «физическими» именами интерфейсов. Эти имена обозначены оборудованию ядром. К несчастью может случиться так, что ядро каждый раз будет назначать разные имена физических интерфейсов одному и тому же оборудованию; например, тот что называется «eth0» после перезагрузки может называться «eth1» или наоборот. Это создаёт проблему, если вы хотите настроить интерфейсы соответствующим образом. Для избежания подобного следует использовать сцеанрии отображения, которые выбирают логические имена интерфейсов в соответствии со свойствами аппаратного интерфейса. Смотри сценарий get-mac-address.sh из каталога примеров, который является примером такого сценария отображения. Смотри также Debian bug #101728.

В настоящее время невозможно разделить /etc/network/interfaces на различные файлы. Возможность, которая сделает это возможным, это некая разновидность директивы включения. В текущей программе ifupdown это не возможно. За более подробной информацией обратитесь Debian bug #159884.

АВТОР

АВТОР ПЕРЕВОДА

СМОТРИ ТАКЖЕ

Для получения консультаций по настройке этого пакета читайте главу Настройка Сети из справочного руководства Debian, который доступен по адресу http://www.debian.org/doc/manuals/reference/ch-gateway.en.html или в пакете debian-reference-en.

Примеры настройки interfaces вы можете найти в /usr/share/doc/ifupdown/examples/network-interfaces.

Источник

Iface delta errors что означает

Сотрудник D-LINK

Зарегистрирован: Чт окт 26, 2017 10:49
Сообщений: 319

Зарегистрирован: Чт фев 08, 2018 07:36
Сообщений: 5

1. Версия прошивки 3.0.3.
2. Сброс к заводским настройкам не производил.
3. Данная проверка не возможна по причине отсутствия в маке разъема. Из устройств большая часть это телефоны, планшеты, смарт тв и приставка.
4. Аналогично 3 пункту.

Вложения:

Снимок экрана 2018-02-09 в 17.25.36.png [ 178.1 KiB | Просмотров: 3154 ]

Вернуться наверх

Сотрудник D-LINK

Зарегистрирован: Чт окт 26, 2017 10:49
Сообщений: 319

2. После отключения функционала перезагрузите роутер.

Остальное оставить по умолчанию.

Зарегистрирован: Чт фев 08, 2018 07:36
Сообщений: 5

2. После отключения функционала перезагрузите роутер.

Остальное оставить по умолчанию.

Данный способ не принес ни каких изменений. Проблема остаться не решенной.

Зарегистрирован: Вс фев 11, 2018 11:10
Сообщений: 2

, LCP reply send in protocol stack sid:32871, id:0
Feb 11 10:47:01 pppd[583]: System time change detected.
Feb 11 10:47:01 pppd[583]: write: Bad address (14)
Feb 11 10:47:01 adsl_status[748]: 1950
Feb 11 10:47:05 update_ntpclient_periodic[766]: date is set, switching off periodic update.
Feb 11 10:47:05 autoupdate[763]: Downloading file: fwupdate.dlink.ru/dislocation
Feb 11 10:47:05 autoupdate[763]: Downloading file: fwupdate.dlink.ru/xDSL/DSL-2640U_RB_U2A_8M/Firmware/exclude
Feb 11 10:47:05 autoupdate[763]: Not found exception
Feb 11 10:47:05 autoupdate[763]: Downloading file: fwupdate.dlink.ru/xDSL/DSL-2640U_RB_U2A_8M/Firmware/latest
Feb 11 10:47:06 autoupdate[763]: Downloading file: fwupdate.dlink.ru/xDSL/DSL-2640U_RB_U2A_8M/Firmware/2017.07.13-15.31_DSL_2640RTL_S_8M_B_3.0.0_release.des
Feb 11 10:47:06 autoupdate[763]: Update not needed
Feb 11 10:47:13 udhcpc[728]: Sending discover.
Feb 11 10:47:15 udhcpc[728]: Sending discover.
Feb 11 10:47:19 udhcpc[728]: Sending discover.
Feb 11 10:47:31 kernel: in func

, LCP reply send in protocol stack sid:32871, id:1
Feb 11 10:47:31 pppd[583]: write: Bad address (14)
Feb 11 10:47:32 udhcpc[728]: Sending discover.
Feb 11 10:47:34 udhcpc[728]: Sending discover.
Feb 11 10:47:38 udhcpc[728]: Sending discover.
Feb 11 10:48:01 kernel: in func

, LCP reply send in protocol stack sid:32871, id:2
Feb 11 10:48:01 pppd[583]: write: Bad address (14)
Feb 11 10:48:31 pppd[583]: write: Bad address (14)
Feb 11 10:48:31 kernel: in func

, LCP reply send in protocol stack sid:32871, id:3
Feb 11 10:48:42 udhcpc[728]: Sending discover.
Feb 11 10:48:44 udhcpc[728]: Sending discover.
Feb 11 10:48:48 udhcpc[728]: Sending discover.
Feb 11 10:49:01 kernel: in func

, LCP reply send in protocol stack sid:32871, id:4
Feb 11 10:49:01 pppd[583]: write: Bad address (14)
Feb 11 10:49:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:5
Feb 11 10:49:32 pppd[583]: write: Bad address (14)
Feb 11 10:49:52 udhcpc[728]: Sending discover.
Feb 11 10:49:54 udhcpc[728]: Sending discover.
Feb 11 10:49:58 udhcpc[728]: Sending discover.
Feb 11 10:50:02 pppd[583]: write: Bad address (14)
Feb 11 10:50:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:6
Feb 11 10:50:31 kernel: in func

, LCP reply send in protocol stack sid:32871, id:7
Feb 11 10:50:31 pppd[583]: write: Bad address (14)
Feb 11 10:51:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:8
Feb 11 10:51:02 pppd[583]: write: Bad address (14)
Feb 11 10:51:03 udhcpc[728]: Sending discover.
Feb 11 10:51:05 udhcpc[728]: Sending discover.
Feb 11 10:51:09 udhcpc[728]: Sending discover.
Feb 11 10:52:02 pppd[583]: write: Bad address (14)
Feb 11 10:52:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:10
Feb 11 10:52:13 udhcpc[728]: Sending discover.
Feb 11 10:52:15 udhcpc[728]: Sending discover.
Feb 11 10:52:19 udhcpc[728]: Sending discover.
Feb 11 10:52:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:11
Feb 11 10:52:32 pppd[583]: write: Bad address (14)
Feb 11 10:53:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:12
Feb 11 10:53:02 pppd[583]: write: Bad address (14)
Feb 11 10:53:23 udhcpc[728]: Sending discover.
Feb 11 10:53:25 udhcpc[728]: Sending discover.
Feb 11 10:53:29 udhcpc[728]: Sending discover.
Feb 11 10:53:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:13
Feb 11 10:53:32 pppd[583]: write: Bad address (14)
Feb 11 10:54:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:14
Feb 11 10:54:02 pppd[583]: write: Bad address (14)
Feb 11 10:54:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:15
Feb 11 10:54:32 pppd[583]: write: Bad address (14)
Feb 11 10:54:32 udhcpc[728]: Sending discover.
Feb 11 10:54:34 udhcpc[728]: Sending discover.
Feb 11 10:54:38 udhcpc[728]: Sending discover.
Feb 11 10:55:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:16
Feb 11 10:55:02 pppd[583]: write: Bad address (14)
Feb 11 10:55:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:17
Feb 11 10:55:32 pppd[583]: write: Bad address (14)
Feb 11 10:55:42 udhcpc[728]: Sending discover.
Feb 11 10:55:44 udhcpc[728]: Sending discover.
Feb 11 10:55:48 udhcpc[728]: Sending discover.
Feb 11 10:56:32 pppd[583]: write: Bad address (14)
Feb 11 10:56:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:19
Feb 11 10:56:52 udhcpc[728]: Sending discover.
Feb 11 10:56:54 udhcpc[728]: Sending discover.
Feb 11 10:56:58 udhcpc[728]: Sending discover.
Feb 11 10:57:31 kernel: in func

, LCP reply send in protocol stack sid:32871, id:21
Feb 11 10:57:31 pppd[583]: write: Bad address (14)
Feb 11 10:58:01 kernel: in func

, LCP reply send in protocol stack sid:32871, id:22
Feb 11 10:58:01 pppd[583]: write: Bad address (14)
Feb 11 10:58:02 udhcpc[728]: Sending discover.
Feb 11 10:58:04 udhcpc[728]: Sending discover.
Feb 11 10:58:08 udhcpc[728]: Sending discover.
Feb 11 10:58:31 kernel: in func

, LCP reply send in protocol stack sid:32871, id:23
Feb 11 10:58:31 pppd[583]: write: Bad address (14)
Feb 11 10:59:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:24
Feb 11 10:59:02 pppd[583]: write: Bad address (14)
Feb 11 10:59:13 udhcpc[728]: Sending discover.
Feb 11 10:59:15 udhcpc[728]: Sending discover.
Feb 11 10:59:19 udhcpc[728]: Sending discover.
Feb 11 11:00:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:26
Feb 11 11:00:02 pppd[583]: write: Bad address (14)
Feb 11 11:00:23 udhcpc[728]: Sending discover.
Feb 11 11:00:25 udhcpc[728]: Sending discover.
Feb 11 11:00:29 udhcpc[728]: Sending discover.
Feb 11 11:00:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:27
Feb 11 11:00:32 pppd[583]: write: Bad address (14)
Feb 11 11:01:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:28
Feb 11 11:01:02 pppd[583]: write: Bad address (14)
Feb 11 11:01:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:29
Feb 11 11:01:32 pppd[583]: write: Bad address (14)
Feb 11 11:01:33 udhcpc[728]: Sending discover.
Feb 11 11:01:35 udhcpc[728]: Sending discover.
Feb 11 11:01:39 udhcpc[728]: Sending discover.
Feb 11 11:02:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:30
Feb 11 11:02:02 pppd[583]: write: Bad address (14)
Feb 11 11:02:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:31
Feb 11 11:02:32 pppd[583]: write: Bad address (14)
Feb 11 11:02:42 udhcpc[728]: Sending discover.
Feb 11 11:02:44 udhcpc[728]: Sending discover.
Feb 11 11:02:48 udhcpc[728]: Sending discover.
Feb 11 11:03:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:32
Feb 11 11:03:02 pppd[583]: write: Bad address (14)
Feb 11 11:03:04 anweb[224]: check need_redirect started
Feb 11 11:03:04 anweb[224]: need_redirect: is defconf
Feb 11 11:03:04 anweb[225]: check need_redirect started
Feb 11 11:03:04 anweb[225]: need_redirect: is defconf
Feb 11 11:03:15 dms_etherwan_read[1545]: start
Feb 11 11:03:15 dms_get_etherwan_port[1545]: start
Feb 11 11:03:15 dms_get_etherwan_port[1545]: end: etherwan port 0
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: start 1
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: end
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: start
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: eth0.5: br0
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: start 2
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: end
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: start
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: eth0.4: br0
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: start 3
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: end
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: start
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: eth0.3: br0
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: start 4
Feb 11 11:03:15 dms_get_etherwan_port_info[1545]: end
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: start
Feb 11 11:03:15 get_gr_name_by_lan_key[1545]: eth0.2: br0
Feb 11 11:03:15 dms_etherwan_read[1545]: end
Feb 11 11:03:15 adsl_status[1552]: 1950
Feb 11 11:03:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:33
Feb 11 11:03:32 pppd[583]: write: Bad address (14)
Feb 11 11:03:52 udhcpc[728]: Sending discover.
Feb 11 11:03:54 udhcpc[728]: Sending discover.
Feb 11 11:03:58 udhcpc[728]: Sending discover.
Feb 11 11:04:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:34
Feb 11 11:04:02 pppd[583]: write: Bad address (14)
Feb 11 11:04:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:35
Feb 11 11:04:32 pppd[583]: write: Bad address (14)
Feb 11 11:05:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:36
Feb 11 11:05:02 pppd[583]: write: Bad address (14)
Feb 11 11:05:02 udhcpc[728]: Sending discover.
Feb 11 11:05:04 udhcpc[728]: Sending discover.
Feb 11 11:05:08 udhcpc[728]: Sending discover.
Feb 11 11:06:02 pppd[583]: write: Bad address (14)
Feb 11 11:06:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:38
Feb 11 11:06:13 udhcpc[728]: Sending discover.
Feb 11 11:06:15 udhcpc[728]: Sending discover.
Feb 11 11:06:19 udhcpc[728]: Sending discover.
Feb 11 11:06:32 pppd[583]: write: Bad address (14)
Feb 11 11:06:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:39
Feb 11 11:07:02 pppd[583]: write: Bad address (14)
Feb 11 11:07:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:40
Feb 11 11:07:23 udhcpc[728]: Sending discover.
Feb 11 11:07:25 udhcpc[728]: Sending discover.
Feb 11 11:07:29 udhcpc[728]: Sending discover.
Feb 11 11:07:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:41
Feb 11 11:07:32 pppd[583]: write: Bad address (14)
Feb 11 11:08:02 pppd[583]: write: Bad address (14)
Feb 11 11:08:02 kernel: in func

, LCP reply send in protocol stack sid:32871, id:42
Feb 11 11:08:32 kernel: in func

, LCP reply send in protocol stack sid:32871, id:43
Feb 11 11:08:32 pppd[583]: write: Bad address (14)
Feb 11 11:08:33 udhcpc[728]: Sending discover.
Feb 11 11:08:35 udhcpc[728]: Sending discover.
Feb 11 11:08:39 udhcpc[728]: Sending discover..

Источник