Kto To

Стандартная болезнь 3310B увы

Никогда не надо вести бизнес с друзьями/родственниками и так далее. Колхоз - это гибельный путь. Лично проходил несколько раз в разных отраслях.

Попытаюсь вам обьяснить. Автор СПЕЦИАЛЬНО допускал ошибки в коде бесплатных версий чтоб доверчивые лохи покупали у него платную. Если вы считаете это нормальным - то я так не считаю.

Тут как всегда самый важный вопрос - убрал ли автор специально допущенные ошибки в коде, которые ненавязчиво подводили доверчивого лоха пользователя к покупке коммерческой версии за баснословные деньги, или не убрал 😎😎😎

Провайдеры в Украине сами виноваты в сложившейся ситуации так как просто не уважают ни себя ни свой труд. Вместо того чтоб нагнуть хомячка установив адекватные цены (в большинстве случаев хомячку просто некуда будет деваться и он вынужден будет платить) провайдеры думая что нагибают конкурента ценами - нагибают в первую очередь самого себя. Среди большинства провайдеров нет бизнесменов - есть ебанутые дебилы для которых как кость в горле то что у соседа хата на метр выше и корова еще не сдохла. Наш хохляцкий менталитет

Положа руку на сердце - дома это самое нужное место где должен хорошо работать вайфай )))

Проблему так и не нашли. Перевели все олты на отдельные вланы. Пока наблюдаем. Обидно что природа проблемы не ясна

Нету. Смотрите - пакет с дхцп запросом проходит от абона до сервера и клиент получает ип. Пакет от клиента на запрос арп сервера проходит до сервера и сервер отвечает и клиент видит арп сервера и начинает слать на сервер ип пакеты. Но пакет от сервера к клиенту на запрос мак адреса клиента - остается без ответа

На сервере никаких крутилок по арп не делалось. Да и абонов в влане порядка 200+-. tcpdump на сервере ничего аномального не показывает :(( Просто когда прилетает ип пакет от клиента - широковещалка с запросом мака клиента, в основном

По сети не производилось никаких изменений ни аппаратных ни настроек.

Абоненты работали до этого долго и счастливо. В схеме ничего не менялось. Проблемы начались три дня назад. Искать что? Пакет от абона долетает до сервера - пакет от сервера, видимо, не долетает до абона ( arp запрос ). Что искать то?

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

Нигде по дороге до абона шторм контроль не включен. Переводим тех абонов которые не работают в другой влан - у них все начинает работать. Коллеги помогите разобраться. За третий день уже мозг сломал себе Не хочется возвращаться к долбаному пппое

Второй день мучаюсь не могу разобраться. Раздается инет методом dhcp option 82 Клиент получает ИП, шлюз, днс от dhcpd но при этом на сервере почему-то его arp выглядит как incomplete. Более глубокий анализ показал следующее. Роутер клиента получает ип, видит мак шлюза, пытается слать какие-то запросы. Пакеты от клиента приходят на сервак 22:20:04.146455 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 71: 10.13.1.49.34647 > 1.1.1.1.53: 21+ A? tp-link.com. (29) 22:20:04.146464 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv

Юра вы идиот. Купите сами себе такой ларек и не давайте тут "советы космического масштаба и космической же глупости". Выкинуть 300к зелени СЕЙЧАС на сеть с 2к абонов которая, вчистую, пусть приносит аж 6к$ в месяц (а грязными дай Бог 3к$) в районе где идут боевые действия и "неизвестно бл%$дь чем все это закончится" - ну тут надо быть очень глубоким отбитым идиотом.

Мы изначально, перед тем как писать, все что можно перепроверить - перепроверили Ошибок на портах нет, потерь на абонентов нет.

Сессия подымается как роутер повторно ломится на подключение. 60-120 секунд как правило судя по логам. Клиентов это напрягает (залипает телек, онлайн игрушки, прочая хрень). Постепенно переводим всех на dhcp но это долгий процесс так как абонов много и физически невозможно это быстро сделать. Но есть места где пока нет возможности перевести на dhcp. Да и все же хочется разобраться почему и исправить.

Ночью добавили в конфиг строчку и перегрузили mpd ( думали что дело в этом) set link keep-alive 60 180 ситуация не поменялась. Дальше присутствуют обрывы правда количество LCP соотв. уменьшилось Dec 16 10:22:45 nas mpd: [vlan17-869] LCP: no reply to 1 echo request(s) Dec 16 10:23:45 nas mpd: [vlan17-869] LCP: no reply to 2 echo request(s) Dec 16 10:23:45 nas mpd: [vlan17-869] LCP: peer not responding to echo requests Идеи, почему это происходит и как полечить уже закончились Можно конечно увеличить максимальный таймаут с 180 секунд до бесконечнос

Стали появляться жалобы от клиентов на обрыв пппое сессий. Проверили - действительно присутствует у некоторых абонентов такая проблема - несколько раз в день обрывается пппое сессия. Вот что в логах Dec 15 11:55:14 nas mpd: [vlan2-153] LCP: no reply to 1 echo request(s) Dec 15 11:55:34 nas mpd: [vlan2-153] LCP: no reply to 1 echo request(s) Dec 15 11:56:29 nas mpd: [vlan2-153] LCP: no reply to 1 echo request(s) Dec 15 11:56:34 nas mpd: [vlan2-153] LCP: no reply to 2 echo request(s) Dec 15 11:56:39 nas mpd: [vlan2-153] LCP: no reply to 3 echo request(s) Dec 15 11:56:44 nas mpd: [vlan

Ha ha, classic 😎

Ее не должно быть. Рынок должен регулировать зарплату. Но это не в нашем гондурасе, увы

Пока ничем. Попробуем поменять олт. Переварка/замена делителей/сплитеров - ничего не дает

Я понимаю НО - на этом же олте/порту - на трех других ветках все работает и при -25 Если б весь порт так работал - вопросов нет, меняли бы модуль/порт/олт. А глянуть в конфиге что китайцы делали - нет возможности?

Отвал чипа у меня был - это выглядит в двух вариантах. 1. Все онушки дисконнект и порт в дауне 2. Все онушки завязаны, опрашиваются, но трафик не бежит. Но так чтоб на 3-х ветках все ок а на одной нет - не похоже на отвал чипа.

Если все заведется - какие выводы?