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 и работать в режиме моста ей не нужно. Вы невнимательно читали - все уже работает, проблему решать не надо.Надо решить лишь с провайдером, который с меня деньги содрал. Пусть вас проблемы радиоканала не волнуют, мы вообще не о них говорим. У вас хата горит, а вы жалуетесь, что сосед газон плохо подстриг. Не лепите сюда серые смарты, они тут вообще неуместны. Ubiquiti это не серые смарты, это достаточно широко используемое оборудование. Поэтому не несите бред. Я не Осипенко, но судя по всему у него нечто подобное было с Вами.... Теперь понятно почему Вы так рьяно выгораживаете прова с такими абсурдными аргументами....

Вынужден повториться: На ОЛТ я блокирую диапазоны MAC-адресов в акцесс-листах, а потом собираю деньги с тех, кому не повезло. Бред - однозначно, но вписывается в Вашу схему. Порт предоставлен - конечно. Поэтому ненадо тут рассказывать про порт и отсутствие ответственности Именно так. Они даже название этому явлению придумали: "недокументированные невозможности". Только вот по факту все оказалось документированным, надо было только читать описание к прошивкам.... ну да, а я в налоговую на провайдера, а потом они на меня в санэпидемстанцию, а я на них пожарникам.... че за детский сад?

А нафига мне интернет на ноутбуке монтажника? Мне он нужен на моем оборудовании. Именно джя этого и есть понятие "сертифицированное оборудование", и это понятие обычно есть во всех договорах с провайдерами. И действует оно не в одну сторону как вам хотелось-бы, а еще и в другую - в пользу абонента. То есть не только если оборудование не сертифицированное можно посылать абонента, но и если оно наоборот сертифицированное - искать проблему у провайдера. По вашему провайдер - это безгрешный ангел и косячить не может по определению? С таким-же успехом можно в акцесс лист добавлять диапазоны мак-адресов и с тех, кто в них попал срубать бабло по описанной выше схеме. А что поделать - вам не повезло, просто потому что мы хотим еще денег...

Хм.... а если-бы я сразу проверил ни не подписал акт? Я взял сертифицированное устройство, хочу его подключить, может я блондинка, которая нефига не шарит? Почему я должен еще и разбираться, что провайдер там что-то еще блокирует? Устройство сертифицировано - сертифицировано, обеспечьте его работу! Вот не надо про Secondary Lan рассказывать... Это далеко не только то, что вы написали. Будь он нужен только для передачи питания в прошивке не было-бы возможности указать его как интерфейс для WAN. У Secondary LAN масса вариантов использования. Есть вполне легальные схемы настройки WAN-подключения на Secondary LAN, погуглите если не верите. Я проблему не придумывал. Я взял устройство с заводским MAC-адресом и захотел его использовать. Ничего нестандартного я при этом не изобретал. А техподдержка провайдера не смогла адекватно решить ситуацию удаленно (хотя в теории могла). может перед тем как выступать с обвинениями хотя-бы википедию почиттать? Намекаю: 1 октет, 1 бит. Называется locally administered. Хотите мак - пробуйте: de:9f:db:e9:d9:32 на основном LAN - точно такой, только первый байт DC

Ситуация следующая: Имеется точка доступа Ubiquiti Nanostation M5 с 2 LAN портами Не знаю по какой причине Ubiquiti на вторичном LAN порту установливает во всех таких точках доступа локально администрируемый MAC-адрес. То есть такой, который не регистрируется в международных реестрах. Потребовалось подключиться с этой точки доступа через GPON и PPPoE к Интернету. Основной LAN использовать для WAN подключения было неудобно, поэтому использовал вторичный, что не запрещается. Настроил точку, приехали монтажники, установили ONU-шку, патч-кордом воткнули во вторичный LAN Nanostation. Все лампочки загорелись, но сразу проверить подключение полноценно не получалось ибо конечное оборудование было в километре по радиоканалу. Поверил лампочкам, подписал акт приемки работ. В итоге выяснилось, что канал не работает. При звонке провайдеру оказалось, что MAC-адрес моей точки доступа провайдер не видит вообще. Первый выезд монтажников ничего не дал, они воткнулись своим ноутбуком в ONU, сказали, что у них все работает и уехали. Ко второму выезду монтажников я подготовился и прописав MAC-адрес точки доступа на ноутбуке(тогда я еще не знал, что проблема в MAC-адресе и прописал его только для того, чтобы обойти возможную привязку к MAC-адресу) продемонстрировал, что ничего не работает. Перебрав с монтажниками кучу вариантов выяснили, что дело в MAC-адресе, поменяли его на точке доступа и все заработало. Провайдер расследовал ситуацию и по итогам заявляет, что виноват я. Ибо использую не сертифицированное оборудование, в котором используется MAC-адрес блокируемый их оборудованием. Показываю сертификаты Ubiquiti доступные в интернете, но это не помогает. Продолжают утверждать, что проблема в моем оборудовании, а значит я должен оплатить за выезды монтажников. Прошу показать источник их уверенности в моей вине, нехотя дают ссылку на этот файл: ftp://ftp.romsat.ua/pub/Lan/BDCOM/P3600-Series/Read_before_Update.txt Оказывается, что блокировка таких как у Ubiquiti адресов выполняется не на уровне железа, а на уровне прошивки OLT, причем появилась эта блокировка лишь начиная с определенной версии прошивки и может быть отключена. В итоге несмотря на все мои обоснованные возражения с меня списали деньги за выезд монтажников. Получается из-за некомпетентности админа, который обслуживает OLT монтажники дважды выезжали для решения проблемы, но платить за это должен клиент... Это вообще нормально со стороны провайдера так делать? Название провайдера пока не пишу, хочу сначала услышать мнение сообщества.