Физического доступа к кабелям уже, естественно нет, все в бетоне.Основное назначение гофры как раз в том, чтобы кабель можно было вытащить из гофры и протянуть новый. Поэтому стараются вести гофру без крутых перегибов, иначе трудно кабель менять.
физические повреждения кабелей исключаются полностью.Значит повреждения математические. :) Ну ещё полтергейст, вуду, диверсия тёмных эльфов и т.п.
iptables-restore: line 4 failedРугается на какие-то правила, но вы их не показали.
iptables-restore: line 75 failed
Problem running '/etc/ufw/before.rules'
hashlimit: FAILпокажите find /lib/modules/ -name '*xt_hashlimit*'
ctstate (NEW): FAILпокажите find /lib/modules/ -name '*xt_conntrack*'
нашел вот такое ...Простым хождением по ссылкам с этой же найденной вами страницы можно в два-три клика (буквально) найти больше:
Comparison of several common line generalization algorithms. Gray: original line (394 vertices), orange: 1973 Douglas-Peucker simplification (11 vertices), blue: 2002 PAEK smoothing (483 vertices), red: 2004 Zhou-Jones simplification (31 vertices). All were run with the same tolerance parameters.
как мне пользоватся комуникатором от сети без акамулятора?Никак, потому что производитель не хотел, чтобы это было возможно. Если слишком много хитропопых будут так воскрешать умершие устройства, то производитель упустит выгоду от продажи новых устройств. А мы знаем, что жаба среднестатистического производителя электроники родилась раньше его самого.
Please ensure all devices within the iommu_group are bound to their vfio bus driver.
You have to pass every device in the group through at once, which isn't going to work for you. The only way to avoid that is to enable the ACS Override kernel patch to split up the group (by pretending the devices can be safely isolated from each other, even though they can't be)
такой интересный момент - если отключить keenetic и после этого зайти на стандартный 192.168.1.1 (на нем keenetic тоже висит) то попадаешь в веб морду DIESEL (старые адсл модемы), откуда он - вообще не понятно.. Физически я его не нашел
Исходим из того, что есть левый DHCP-сервер.
Также исходим из того, что настоящим DHCP-сервером является ваш роутер Микротик (или это не так?)
Сколько у вас свитчей на заводе? Пусть десять-двадцать, если это мелкие 8-портовые свитчи.
Ноутбук в хозяйстве найдётся? С ним просто намного меньше бегать придётся, чем без него.
Идёте с ноутом к первому свитчу (любому на выбор).
1. определяете, какой из кабелей в свитче является ап-линком, т.е. идёт в сторону вашего главного роутера. Если через несколько промежуточных свитчей идёт к роутеру - неважно, всё равно - это up-link. Надеюсь, не надо подробно рассказывать, как определить? :) Помечаете этот кабель изолентой (если он ещё не был помечен).
2. выдёргиваете из свитча ап-линк и цепляете к свитчу ноутбук. На ноутбуке смотрите одно из двух: либо левый DHCP выдаст адрес, либо ноут подождёт-подождёт, не увидит DHCP и сам себе выберет адрес 169.254.*.* От правильного DHCP не может быть ответа, т.к. ап-линк выдернут.
Лучше конечно, чтобы сейчас попался левый DHCP. Если не попался, то втыкаем ап-линк на место и идём к любому другому свитчу. За одну-две минуты без интернета пользователи (которые висят на этом свитче) сильно не обломаются. Знаем мы все эти заводы, работали, :) главное, чтобы директору не отрубить интернет, а все остальные потерпят, если недолго. :) Хотя можно и согласовать заранее, как выше советовали. Только в этом случае вы же не выключаете все компы, а просто делаете кратковременные перебои с интернетом - сущие пустяки, пф-ф-ф...
3. дошли до N-го свитча, повторили всё, и поймали ответ левого DHCP. Ура! Выдёргиваем все-все кабели из свитча (и ноут тоже), вставляем один кабель (не ап-линк!) и вставляем ноут. Ловим DHCP. нет? выдёргиваем ноут, добавляем один кабель в свитч (не ап-линк!) Ловим DHCP. и т.д. Поймали? помечаем как-то последний кабель (изолентой другого цвета, и назовём это условно "злым" кабелем). Ура! Уже большой прогресс: знаем, что левый DHCP где-то на этом кабеле (если мы не ошиблись, лучше сразу ещё раз проверить).
4. дальше по обстановке: есть возможность тупо идти вдоль этого кабеля и дойти до следующего свитча? Отлично! Идём и там всё повторяем с пункта 3.
5. Нет возможности проследить по кабелю, например, пучок кабелей уходит в стену или в потолок. Тогда выдёргиваем из свитча "злой кабель" и ходим по заводу - ищем комнату с компами, на которых пропал интернет, или сразу свитч, на котором не горит индикатор на ап-линке. Нашли такой свитч? Проверяем: втыкаем "злой кабель", возвращаемся к найденному свитчу. Появился ап-линк? значит не ошиблись. Повторяем на этом свитче пункт 3.
6. Если запутались и сил нет дальше искать, то оставляем выдернутым последний (только последний!) найденный "злой кабель". Раз непонятно, куда он идёт, то сидим ждём, кто из пользователей начнёт жаловаться на отсутствие интернета. Как пожалуются - идём туда и ищем свитч. А если никто не пожалуется, то и хрен с ним. Источник проблем мы ведь изолировали от локальной сети, может позже выяснится, кто это.
Всё! конец алгоритма поиска! В итоге должны прийти к устройству с левым DHCP.
What's New in the Windows API
- Windows 8 Technologies
- Windows 8 API List
- Windows 7 Technologies
- Windows 7 API List
- Windows Server 2008 Technologies
- Windows Vista Technologies
- Windows Vista API List
Как быть в этом случае? Создавать единую таблицу с кучей null или же несколько раздельных таблиц? Или делать таблицу для общих свойств и вспомогательные таблицы для дополнительных свойств? Может, есть некая общепринятая практика в этом случае?Нет чёткой общепринятой практики, потому что в разных случаях оптимальное решение может быть разное, в зависимости от постановки задачи.