Kto To
-
Всього повідомлень
1 960 -
Приєднався
-
Останній візит
-
Дней в лидерах
38
Тип контенту
Профили
Форум
Календарь
Сообщения додав Kto To
-
-
В 19.05.2023 в 12:42, Paramotor сказал:
Не пойму вас. Автор вложил свои знания, силы , деньги в разработку и берет за это деньги. Устраивает вас вы покупаете если нет ищите другой продукт. Если автор хочет он может сделать халявный продукт, а может и не сделать то такое
К чему тогда ваш комент? Вы можете написать свой билинг и дать в абсолютно бесплатное пользование пользователям форума. Спасибо скажут я думаю за такое
Попытаюсь вам обьяснить. Автор СПЕЦИАЛЬНО допускал ошибки в коде бесплатных версий чтоб доверчивые лохи покупали у него платную. Если вы считаете это нормальным - то я так не считаю.
-
Тут как всегда самый важный вопрос - убрал ли автор специально допущенные ошибки в коде, которые ненавязчиво подводили доверчивого
лохапользователя к покупке коммерческой версии за баснословные деньги, или не убрал 😎😎😎-
1
-
-
Провайдеры в Украине сами виноваты в сложившейся ситуации так как просто не уважают ни себя ни свой труд. Вместо того чтоб нагнуть хомячка установив адекватные цены (в большинстве случаев хомячку просто некуда будет деваться и он вынужден будет платить) провайдеры думая что нагибают конкурента ценами - нагибают в первую очередь самого себя. Среди большинства провайдеров нет бизнесменов - есть ебанутые дебилы для которых как кость в горле то что у соседа хата на метр выше и корова еще не сдохла. Наш хохляцкий менталитет
-
9
-
-
Положа руку на сердце - дома это самое нужное место где должен хорошо работать вайфай )))
-
1
-
5
-
-
Проблему так и не нашли. Перевели все олты на отдельные вланы. Пока наблюдаем. Обидно что природа проблемы не ясна
-
20 часов назад, skybetik сказал:
По пути есть edge core switch?
Нету.
Смотрите - пакет с дхцп запросом проходит от абона до сервера и клиент получает ип.
Пакет от клиента на запрос арп сервера проходит до сервера и сервер отвечает и клиент видит арп сервера и начинает слать на сервер ип пакеты.
Но пакет от сервера к клиенту на запрос мак адреса клиента - остается без ответа
-
20 часов назад, ISK сказал:
На размер ARP таблицы лимиты никакие не установлены?
На сервере никаких крутилок по арп не делалось. Да и абонов в влане порядка 200+-. tcpdump на сервере ничего аномального не показывает :(( Просто когда прилетает ип пакет от клиента - широковещалка с запросом мака клиента, в основном
-
7 часов назад, carver сказал:
тоже что-то такое вроде слышал. несколько лет назад.
интеграторы поставили на автономный погрузчик какие-то "индастриал свичи" на 100Мб,и налепили на него "проф-камер" с битретом в 20 Mb, еще и по вайфай собирались все это передавать ))
но проблема вылезла еще на свичах, резали мультикаст от камер.
так-что, соглашусь, изменение в "IPTV" - вполне могли что-то изменить.По сети не производилось никаких изменений ни аппаратных ни настроек.
-
10 минут назад, nedoinet сказал:
Маки абонентов не попадают случаем в Locally Administered MAC addresses?
Абоненты работали до этого долго и счастливо. В схеме ничего не менялось. Проблемы начались три дня назад.
19 минут назад, Туйон сказал:Если в влане много людей - ищи.
Искать что? Пакет от абона долетает до сервера - пакет от сервера, видимо, не долетает до абона ( arp запрос ). Что искать то?
-
3 минуты назад, Туйон сказал:
А что за железо там вообще?
Абоненты между собой по L2 не общаются, Vlan на каждого клиента или я как понял в одном Vlan множество клиентов?
Если так, может какой-то роутер флудит.Олты бдком. Между ними магистральные свитчи. В одном влан пачка клиентов. Пакеты от клиентов прилетают на сервер, но арп запрос отправленный от сервера к клиенту остается без ответа. Так не у всех но у пачки клиентов такая проблема. Причем на олте могут быть клиенты которые нормально работают и которые не работают.
-
2 часа назад, Kiano сказал:
У меня похожая фигня была, но на микротах. По пути до абона на свитчах стоял шторм контрол и прочие ограничения на юникаст и бродкаст. Вот, их потюнить для начала.
Нигде по дороге до абона шторм контроль не включен. Переводим тех абонов которые не работают в другой влан - у них все начинает работать.
Коллеги помогите разобраться. За третий день уже мозг сломал себе
Не хочется возвращаться к долбаному пппое
-
Второй день мучаюсь не могу разобраться.
Раздается инет методом 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.
В общем мучаюсь второй день не могу разобраться. Возможно кто-то сталкивался с данной проблемой и может помочь решить.
-
В 06.05.2022 в 10:27, ura173051 сказал:
господа , если вы не шарите , то не пишите , абонент тут вообще ни причем , и месячная плата тоже , тут продается ВОЗМОЖНОСТЬ , это как киоск на рынке ! ты хочешь стать продавать а не куда , вот и приходится рыбное место выкупать в 2 ито и в 5 дорого !
вы сейчас попробуйте , просто подписать договор с ОСББ с новым провайдером , будете идти в след за кораблем ! или новый ремонт делать в подъезде!Юра вы идиот. Купите сами себе такой ларек и не давайте тут "советы космического масштаба и космической же глупости". Выкинуть 300к зелени СЕЙЧАС на сеть с 2к абонов которая, вчистую, пусть приносит аж 6к$ в месяц (а грязными дай Бог 3к$) в районе где идут боевые действия и "неизвестно бл%$дь чем все это закончится" - ну тут надо быть очень глубоким отбитым идиотом.
-
3
-
2
-
-
Мы изначально, перед тем как писать, все что можно перепроверить - перепроверили
Ошибок на портах нет, потерь на абонентов нет.
-
7 часов назад, DAK сказал:
Сессия сразу восстанавливается или некоторое время не может подключиться?
Сессия подымается как роутер повторно ломится на подключение. 60-120 секунд как правило судя по логам. Клиентов это напрягает (залипает телек, онлайн игрушки, прочая хрень).
5 часов назад, NETOS сказал:А нафига оно вообще надо отэто РРРоЕ ? Может уже пора переходить на более современные методы авторизации?
Постепенно переводим всех на 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: [vlan2-153] LCP: no reply to 4 echo request(s) Dec 15 11:56:49 nas mpd: [vlan2-153] LCP: no reply to 5 echo request(s) Dec 15 11:56:54 nas mpd: [vlan2-153] LCP: no reply to 6 echo request(s) Dec 15 11:56:59 nas mpd: [vlan2-153] LCP: no reply to 7 echo request(s) Dec 15 11:56:59 nas mpd: [vlan2-153] LCP: peer not responding to echo requestsВся сеть построена на ПОН, у клиентов которые жалуются уже поменяли все - роутер/ону/патчкорды/переварили оптику. Количество жалоб потихоньку увеличивается. По магистралям и на сервере также все проверили на предмет ошибок на портах и так далее. Проблема возникает у разных клиентов в разных частях сети, линки к разным частям сети бегут разными маршрутами что исключает глючный коммутатор. Проблема возникает не только в ЧНН а в любое время суток. Начал задумываться возможно что-то в конфиге мпд надо подкрутить или еще в чем-то. Если не сложно - поделитесь рабочим (без подобных глюков) конфигом для мпд ну и возможно у кого-то было подобное и как-то решали данную проблему
-
Ha ha, classic 😎
-
1 минуту назад, Чучундра сказал:
Маленькая минималка - плохо, большая минималка - тоже плохо. А какая тогда она должна быть ?
Ее не должно быть. Рынок должен регулировать зарплату. Но это не в нашем гондурасе, увы
-
2
-
-
В 15.07.2021 в 10:27, blackjack сказал:
Чим закінчилась епопея?
Пока ничем. Попробуем поменять олт. Переварка/замена делителей/сплитеров - ничего не дает
-
57 минут назад, rmx сказал:
была подобная проблема с бдком GP3600-16
на одном из портов новой линии переключили порядка 20 абонентов, через короткое время начался отвал, при том что сигнал был в раене -21
неделю общения с ДЕПСОМ, (проверить линию, заменить модуля, заменить все делители, заменить все ону, проверка конфига, смена пришивки, засвет ону с хорошим сигналом, танцы с бубном..)
в итоге дошли до китайских инженеров которые заходили на голову, что то делали, и через пару часов все заработало и больше отвалов не было.
что делали китайцы некто не знает
все тянулось порядка недели, при том что все абоненты было из корпоративного сектора
советую идти тем же путем.
Я понимаю
НО - на этом же олте/порту - на трех других ветках все работает и при -25 Если б весь порт так работал - вопросов нет, меняли бы модуль/порт/олт. А глянуть в конфиге что китайцы делали - нет возможности?
-
5 часов назад, Dimkers сказал:
Порт или модуль. А учитывая что у тебя 3310Б - они болеют отвалами чипов....
Отвал чипа у меня был - это выглядит в двух вариантах.
1. Все онушки дисконнект и порт в дауне
2. Все онушки завязаны, опрашиваются, но трафик не бежит.
Но так чтоб на 3-х ветках все ок а на одной нет - не похоже на отвал чипа.
-
54 минуты назад, Dimkers сказал:
Отключи рабочую сосееднюю ветку с соседнего порта и в тот же порт воткни нерабочую ветку. Так ты точно уберешь из цепочки порт и СФП. Если нерабочая ветка заработает в соседнем заведомо рабочем порту - то вывод примерно ясен.
По вопросу каши - сохрани конфиг, отбиндь все ОНУ с рабочей ветки, переткни нерабочую ветку в заведомо рабочую, новые прибьются автоматом. Посмотри результат. Затем верни все назад. Делов на 15 минут, потерпят твои юрики. Можно вообще в небизнесс время провернуть это.
но дело твое. Я не один тебе говорю этот вариант.
Если все заведется - какие выводы?
-
16 часов назад, skybetik сказал:
Так вы Рефом смотрели что там по 1310 или нет ?
Отключили ветку от олта и проверяли или светит что-то с ветки. Ничего не видно.
15 часов назад, a_n_h сказал:тогда только на какой-то из сварок затухание на 1310 гораздо больше чем на 1490. Что на ОЛТ на этой ветке на рабочих онушках видно?
Уровни ОТ олта и НА олт - соответсующие (нет просадки ни в одну ни в другую сторону - это проверили в первую очередь)
Захоплення інтернет провайдера НЕТМАСТЕР.
в Мережа - бізнес
Опубліковано:
Никогда не надо вести бизнес с друзьями/родственниками и так далее.
Колхоз - это гибельный путь. Лично проходил несколько раз в разных отраслях.