dmitriyrsl
МаглыТип контенту
Профили
Форум
Календарь
Все, що було написано dmitriyrsl
-
То есть провайдер считая, что мое положение уязвимо, решил этим воспользоваться в корыстных целях? Это уже криминальная статья... Затрудняюсь сейчас ее назвать, но что-то я такое уже встречал... Да, вижу ссылку. Но последнее сообщение читали? Там ТП-линк использовал "locally administered" адрес и закончилось все всеравно вопросом к BDCOM. И кстати не факт, что подобное поведение BDCOM являлось правильным... Все в порядке с этой точкой. Законно куплена и используется. БП от нее имеется.
-
то, что эти адреса отправляются на все ОНУ-шки - это бабка надвое сказала. Я не вижу пруфов об этом. зато я вижу, что такое решение используется другими провайдерами: https://forum.nag.ru/index.php?/topic/147199-bdcom-p3608-dhcp-ne-vidit-zaprosov/ и никто в этом ничего зазорного не видит И это только одна из ссылок по запросу "epon local-mac forward" насчет суда я вам ответил в личке. к изначальной теме это никак не относится.
-
вот с последним согласен.Но никто мне выдержек их спецификаций не представлял. Сослались лишь на текстовый файл с описания к прошивке. А где написано, что данные мак-адреса недопустимы? Они не регистрируются в глобальных реестрах - да, но кто сказал что их надо блочить? И даже если надо блочить, то почему провайдер гонял свою бригаду за мой счет, а не решил это со своей стороны?
-
А теперь представим картину: Появляется новый дешевый вендор, который массово использует маки из заблоченного диапазона. И клиенты пачками начинают покупать его девайсы. Провайдер видя такую толпу прогибается и убирает блокировку (или прогибается BDCOM и убирает ее как дефолт)... И что теперь делать тому клиенту, который оказался самым первым и потому пострадал? Провайдер должен решать свои проблемы не за счет абонента. И во всех сомнительных ситуациях "клиент всегда прав". В договоре провайдера нет ничего о том, что я должен использовать только девайсы определенного вендора или не использоват
-
тут даже вопрос не в том, что они блочат (наверно эдакий метод борьбы с флудом ибо маки действительно редко такие попадаются), а в том, что это отключаемо и почему провайдер об этом не знал...
-
да ладно.... если никто не делал эксперимент, то откуда вообще эта тема взялась? Откуда взялся файл с описанием к прошивке? Свой мак с привел выше, диапазон блокируемых маков тут уже в нескольких сообщениях фигурировал....
-
блокируется даже не вендор.... блокируются local administered маки. Это у любого вендора такое может быть. Я выше привел пример с 3COM, они даже ухитрились такой диапазон маков зарегистрировать.
-
А где написано, что Ubiquiti операторское оборудование? откуда вообще такое деление? Они СПЕЦИАЛЬНО блокировали! Они тупо не читают описания к прошивкам, которые ставят. Почему я должен платить за их косяк? Для меня данная точка доступа - это "домашний тплинк". Докажите обратное
-
Вы вообще изначальное сообщение читали? Поняли о чем оно? Каким боком радиоканал к этому сообщению? Если Вас так напрягает Ubiquiti, возьмем другого вендора: MAC адрес: 02-60-8C (hex) Вендор: 3COM CORPORATION MAC адрес: 02-C0-8C (hex) Вендор: 3COM CORPORATION Он тоже не будет работать. Что, теперь уже 3COM виноват? Опять всякое гавно пихают в наше идеальное оборудование! Наша ответственность закончилась на конечной точке, идите со своим 3COM-ом.... Что хотим то и блочим! Подстраивайтесь! Провайдер всегда прав!
-
Это специфика связанная с получением питания.Так было удобнее вобщем.
-
а физики значит должны страдать по определению? их удел терпеть? Такое как у меня оборудование еще у кучи абонентов, просто им повезло воткнуться main-портом. Давайте провайдеры будут всех клиентов с Ubiquiti блочить - ибо нех! Main-порт целиком рабочий и по нему поступает питание. А причем тут вдс? Причем тут драная галоша? Мы разве о радиоканале говорим? Точка доступа выступает раутером, она поднимает PPPoE и работать в режиме моста ей не нужно. Вы невнимательно читали - все уже работает, проблему решать не надо.Надо решить лишь с провайдером, который с меня деньги содрал.
-
Вынужден повториться: На ОЛТ я блокирую диапазоны MAC-адресов в акцесс-листах, а потом собираю деньги с тех, кому не повезло. Бред - однозначно, но вписывается в Вашу схему. Порт предоставлен - конечно. Поэтому ненадо тут рассказывать про порт и отсутствие ответственности Именно так. Они даже название этому явлению придумали: "недокументированные невозможности". Только вот по факту все оказалось документированным, надо было только читать описание к прошивкам.... ну да, а я в налоговую на провайдера, а потом они на меня в санэпидемстанцию, а я на них пожарникам.
-
А нафига мне интернет на ноутбуке монтажника? Мне он нужен на моем оборудовании. Именно джя этого и есть понятие "сертифицированное оборудование", и это понятие обычно есть во всех договорах с провайдерами. И действует оно не в одну сторону как вам хотелось-бы, а еще и в другую - в пользу абонента. То есть не только если оборудование не сертифицированное можно посылать абонента, но и если оно наоборот сертифицированное - искать проблему у провайдера. По вашему провайдер - это безгрешный ангел и косячить не может по определению? С таким-же успехом можно в акцесс лист добавлять диапазо
-
Хм.... а если-бы я сразу проверил ни не подписал акт? Я взял сертифицированное устройство, хочу его подключить, может я блондинка, которая нефига не шарит? Почему я должен еще и разбираться, что провайдер там что-то еще блокирует? Устройство сертифицировано - сертифицировано, обеспечьте его работу! Вот не надо про Secondary Lan рассказывать... Это далеко не только то, что вы написали. Будь он нужен только для передачи питания в прошивке не было-бы возможности указать его как интерфейс для WAN. У Secondary LAN масса вариантов использования. Есть вполне легальные схемы настройки WAN-
-
Ситуация следующая: Имеется точка доступа Ubiquiti Nanostation M5 с 2 LAN портами Не знаю по какой причине Ubiquiti на вторичном LAN порту установливает во всех таких точках доступа локально администрируемый MAC-адрес. То есть такой, который не регистрируется в международных реестрах. Потребовалось подключиться с этой точки доступа через GPON и PPPoE к Интернету. Основной LAN использовать для WAN подключения было неудобно, поэтому использовал вторичный, что не запрещается. Настроил точку, приехали монтажники, установили ONU-шку, патч-кордом воткнули во вторичный LAN Nanostation. Все ламп