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 IPv4 (0x0800), length 68: 10.13.1.49.34647 > 1.1.1.1.53: 22+ A? bing.com. (26) 22:20:04.146501 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 78: 10.13.1.49.37418 > 8.8.8.8.53: 6096+ A? a.root-servers.net. (36) 22:20:04.146507 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 71: 10.13.1.49.34647 > 8.8.8.8.53: 19+ A? tp-link.com. (29) 22:20:04.146511 5c:a6:e6:2a:55:a4 > 00:1b:21:ba:b7:15, ethertype IPv4 (0x0800), length 68: 10.13.1.49.34647 > 8.8.8.8.53: 20+ A? bing.com. (26) и при этом сервак пытается определить мак клиента отправляя arp запрос 22:19:54.170633 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 22:19:55.170640 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 22:19:56.171657 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 22:19:58.170317 00:1b:21:ba:b7:15 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.13.1.49 tell 10.13.0.1, length 28 И не получается от клиентского роутера ответ. Причем проблема с некоторыми клиентами (не со всеми). Также непонятно зачем шлется arp запрос если на сервер приходит ipv4 пакет уже с мак адресом клиента? Если я прибиваю arp -S мак клиента - у клиента все начинает счастливо работать. Через какое-то время если таки клиентское железо отвечает на запрос и мак добавляется в таблицу на серваке - все также счастливо работает пока не пройдет таймаут и мак не удалится. Если мак появляется и его удалить принудительно - то заново он не добавляется и снова висит в incomplete. В общем мучаюсь второй день не могу разобраться. Возможно кто-то сталкивался с данной проблемой и может помочь решить.

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