Ой, случайно отправил.
Мне кажется, что определяющими тут являются команды:
movlw b'01010000
movlw b'01100000
movlw b'10100000
movlw b'10010000
, и задержки между ними.
Позиционируя статью, как «для новичков», именно на этом стоило заострить внимание, и пояснить, что происходит на выходах микроконтроллера, и какое влияние это оказывает на подключенную аналоговую схему. Получается, что статья описывает как сделать, не объясняя, почему это работает. А ведь именно глубокое понимание залог успеха.
А вообще, я рад видеть на хабре блог по микроконтроллерам, хотя эта тематика действительно не типичная для хабра. Ну что же, все течет, все меняется.
Знаком с PIC-ушками, хотя предпочитаю Atmel. Со своей стороны постараюсь вас поддержать в данном начинании, а может и сам чего напишу.
Ну а пока только критика. Я все же убежден, что понимание важнее результата.
Пусть уж лучше не работает, зато ты понимаешь, почему оно не работает, нежели оно будет работать, но ты не понимаешь почему.
Да конешно, для аткаи на корпоративную сеть лучше использовать специальное ПО, позволяющее сформировать любой пакет, а не таскать с собой МФУ внушительных размеров. =)
Я рассмотрел ситуацию чисто гипотетически, указав, что все зависит от настроек маршрутизации, но в принципе такое возможно.
VLAN в данном контексте стоит рассматривать лишь как единый широковещательный домен второго уровня, ну или проще говоря одну физическую сеть. Правда виртуальную. Они тут не при чем, т.к. маршрутизация — это уже третий уровень, а VLAN-ы исключительно второй.
> сканером в МФУ пользуются чрезвычайно редко
В это сложно поверить, но я видел своими собственными глазами!
Скорость сканирования у это МФУ чисто визуально близка к странице в секунду.
В него заряжают стопку договоров, и он их сканит с бешенной скоростью.
Дык вот, что бы перезагрузить МФУ, мы каждый раз были вынуждены дожидаться окончания процесса сканирования. Сложилось впечатление, что МФУ-шка сканирует документы 8 часов в день, каждый день. Это по странице в секунду!
Драйвер принтера + дополнительное ПО.
Оно необходимо для реализации функции сетевого сканера в первую очередь. Заметьте МФУ имеет сетевой порт Ethernet, т.е. это полноценный сетевой сканер. А также для мониторинга принтеров. Это ПО кстати обнаруживает все принт-сервера в сети, и очень хорошо подходит для их мониторинга(оно цепляет все наши HP-шники, а это около сотни!). В главном окне выводиться весь список принтеров и их текущее состояние — например «Готов», или «кончился картридж», «нет бумаги» и т.д. Вообще-то очень удобно. Само ПО проблем не вызывает, и нареканий к нему нет… ну пока оно не услышит зов МФУ =)
NetWare — зона ответственности серверистов, а я все же сетевик. Как следствие дать подробного и развернутого ответа не могу.
Но на сколько я понимаю NetWare — это лишь пережиток прошлого, и сейчас его роль сведена лишь до каталогов директорий(организация доступа к ресурсам) и файл-серверов. Но повторюсь, я могу ошибаться.
С удовольствием принимаю вашу критику!
Было два варианта:
1. Не писать сразу про МФУ в углу комнаты, и тогда читатель подсознательно искал бы в статье ответ на вопрос КТО? Кто же виноват в этом?
2. Начав статью с недвусмысленного намека на виновника, я переключил интерес читателя на поиски ответа на вопрос ПОЧЕМУ? А именно это и было главной идей статьи. Не найти виновника, а понять почему так происходит.
А за дельную критику в литературном(а не техническом) ракурсе — спасибо.
1. момент времени, когда происходит перезагрузка не влияет на дальнейшее развитие событий, хоть это 00:00:00, хоть 00:00:02.
2. Да, при таком стечении обстоятельств предложенное вами решение растянет волну во времени, и снимет все наведенные проблемы. Но во первых такое решение это заплатка, а не решение проблемы на корню. Во-вторых, разве могли такое предположить разработчики ПО для МФУ класса SOHO(SmallOfficeHomeOffice)? Я думаю им простительно.
3. Чем меньше интервал времени между реальным изменением топологии сети, и сбросом MAC-таблиц, тем меньше вероятность дропа(потери) пакетов. Одно лечим, другое калечим. К тому же этот интервал можно вручную настроить в IOS(операционная система, применяемая на оборудовании cisco) разным на разных устройствах. Но все же в идеале нужно стремиться к минимальному значению, и одинаковому поведению(стандартизация) всех узлов сети. Иначе, когда, как вы предлагаете такие временные интервалы будут определяться случайным образом, диагностировать проблемы в сети станет в разы сложнее!
если вопрос к автору, то отвечаю:
с такой увлекательной работой и большими возможностями профессионального роста(не карьерного, а именно профессионального) — это не важно!
а вообще не много =\
Долго думал, что вам ответить.
Во-первых, позволю себе заметить, что в статье после 5-го пункта есть абзац содержащий такие фразы:
"… не точен и скуп на факты."
"… вообще говоря все не совсем так, хотя очень близко."
«краткое описание принципов STP и причин возникновения unicast-flood’а потянет еще на две три статьи.»
Во-вторых, во общем, я с вами согласен, но есть некоторые особенности, которые я не осветил, а вы не учли.
Я предлагаю написать небольшую отдельную статью в блоге Cisco, с описанием особенностей работы коммутаторов серии cisco2950. Там я подробно изложу свою точку зрения, с соответствующими аргументами. И если у вас останутся вопросы, то мы сможем обсудить их в комментариях к той статье, так как это уже вопросы более специфические.
А эти МФУ только как сканер и используют.
Не зря же в сети под сотню принт-серверов HP-шных. =)
А мороки никакой — тот же софт, тот же IP прописать.
Либо на клиентах, либо в DNS.
А клиенты настроить на DNS имя.
Учитывая мой скромный опыт общения со службой принт-сервера на базе Win2003, мне не ясно, как это может решить проблему?
Ну только если выводить МФУ в другую подсеть в другом vlan-е…
А это можно сделать и без принт-сервера, т.к. клиентское ПО можно настроить по IP.
Мы рассматривали множество вариантов решения. И выводить МФУ в отдельный vlan, и в отдельную подсеть с маршрутизацией, и вырезать порты на на клиентах…
Но как это не странно самым оптимальным решением является все же именно настройка корректного времени.
Был поставлен эксперимент. В 18-00 все сотрудники уходят, выключая свои машины. Перезагрузка МФУ в 19-00 не дает никакого эффекта! Просто некому ответить на эти пакеты, а если кто и задержался на работе, то что там какие-то 200-300 пакетов?
Вот так! Все гениальное просто.
ошибка одна — системное время на МФУ, а настройка МФУ не имеет отношения к сетевому администрированию.
назвать cisco2950 — тупым свичом… у меня язык не поворачивается. да, не корпоративный уровень, но никак не тупая.(vlan тут не при чом)
открытые порты — а зачем закрывать порты в сети, которая находиться за множеством фаерволов? и опять таки это не имеет отношение к сетевому администрированию
стоит учесть стечение обстоятельств.
1) это ПО должно быть на множестве клиентов в данной подсети(допустим распространить вирусом)
2) в данной подсети должно быть множество устройств, работающих с SNMP в комьюнити public
3) TC(Topology Change) — вызываны слабым железом. с одной стороны в сети может и не быть таких железок. с другой стороны вся сеть может быть построена только на них, и тогда…
4) есть один интересный момент, в дампе четко видно TTL=1, что не позволяет пакету покидать данную подсеть… а если IP.TTL = '255', то большому кораблю большое плавание! Но тут уже все зависит от настроек маршрутизации…
полностью с вами согласен, по поводу размеров подсети
и проблема эта известная.
еще хуже то, что этот широковещательный домен размазан по 30+ коммутаторам и двум зданиям!
но увы, есть причины(от админов независящие), по которым ситуация остается неизменной и решение этих проблем отложено на неопределенный срок.
а проблем с производительностью на практике нет.
Мне кажется, что определяющими тут являются команды:
movlw b'01010000
movlw b'01100000
movlw b'10100000
movlw b'10010000
, и задержки между ними.
Позиционируя статью, как «для новичков», именно на этом стоило заострить внимание, и пояснить, что происходит на выходах микроконтроллера, и какое влияние это оказывает на подключенную аналоговую схему. Получается, что статья описывает как сделать, не объясняя, почему это работает. А ведь именно глубокое понимание залог успеха.
А вообще, я рад видеть на хабре блог по микроконтроллерам, хотя эта тематика действительно не типичная для хабра. Ну что же, все течет, все меняется.
Знаком с PIC-ушками, хотя предпочитаю Atmel. Со своей стороны постараюсь вас поддержать в данном начинании, а может и сам чего напишу.
Ну а пока только критика. Я все же убежден, что понимание важнее результата.
Пусть уж лучше не работает, зато ты понимаешь, почему оно не работает, нежели оно будет работать, но ты не понимаешь почему.
movlw b'01100000
Я рассмотрел ситуацию чисто гипотетически, указав, что все зависит от настроек маршрутизации, но в принципе такое возможно.
VLAN в данном контексте стоит рассматривать лишь как единый широковещательный домен второго уровня, ну или проще говоря одну физическую сеть. Правда виртуальную. Они тут не при чем, т.к. маршрутизация — это уже третий уровень, а VLAN-ы исключительно второй.
В это сложно поверить, но я видел своими собственными глазами!
Скорость сканирования у это МФУ чисто визуально близка к странице в секунду.
В него заряжают стопку договоров, и он их сканит с бешенной скоростью.
Дык вот, что бы перезагрузить МФУ, мы каждый раз были вынуждены дожидаться окончания процесса сканирования. Сложилось впечатление, что МФУ-шка сканирует документы 8 часов в день, каждый день. Это по странице в секунду!
Оно необходимо для реализации функции сетевого сканера в первую очередь. Заметьте МФУ имеет сетевой порт Ethernet, т.е. это полноценный сетевой сканер. А также для мониторинга принтеров. Это ПО кстати обнаруживает все принт-сервера в сети, и очень хорошо подходит для их мониторинга(оно цепляет все наши HP-шники, а это около сотни!). В главном окне выводиться весь список принтеров и их текущее состояние — например «Готов», или «кончился картридж», «нет бумаги» и т.д. Вообще-то очень удобно. Само ПО проблем не вызывает, и нареканий к нему нет… ну пока оно не услышит зов МФУ =)
Но на сколько я понимаю NetWare — это лишь пережиток прошлого, и сейчас его роль сведена лишь до каталогов директорий(организация доступа к ресурсам) и файл-серверов. Но повторюсь, я могу ошибаться.
Было два варианта:
1. Не писать сразу про МФУ в углу комнаты, и тогда читатель подсознательно искал бы в статье ответ на вопрос КТО? Кто же виноват в этом?
2. Начав статью с недвусмысленного намека на виновника, я переключил интерес читателя на поиски ответа на вопрос ПОЧЕМУ? А именно это и было главной идей статьи. Не найти виновника, а понять почему так происходит.
А за дельную критику в литературном(а не техническом) ракурсе — спасибо.
2. Да, при таком стечении обстоятельств предложенное вами решение растянет волну во времени, и снимет все наведенные проблемы. Но во первых такое решение это заплатка, а не решение проблемы на корню. Во-вторых, разве могли такое предположить разработчики ПО для МФУ класса SOHO(SmallOfficeHomeOffice)? Я думаю им простительно.
3. Чем меньше интервал времени между реальным изменением топологии сети, и сбросом MAC-таблиц, тем меньше вероятность дропа(потери) пакетов. Одно лечим, другое калечим. К тому же этот интервал можно вручную настроить в IOS(операционная система, применяемая на оборудовании cisco) разным на разных устройствах. Но все же в идеале нужно стремиться к минимальному значению, и одинаковому поведению(стандартизация) всех узлов сети. Иначе, когда, как вы предлагаете такие временные интервалы будут определяться случайным образом, диагностировать проблемы в сети станет в разы сложнее!
с такой увлекательной работой и большими возможностями профессионального роста(не карьерного, а именно профессионального) — это не важно!
а вообще не много =\
Во-первых, позволю себе заметить, что в статье после 5-го пункта есть абзац содержащий такие фразы:
"… не точен и скуп на факты."
"… вообще говоря все не совсем так, хотя очень близко."
«краткое описание принципов STP и причин возникновения unicast-flood’а потянет еще на две три статьи.»
Во-вторых, во общем, я с вами согласен, но есть некоторые особенности, которые я не осветил, а вы не учли.
Я предлагаю написать небольшую отдельную статью в блоге Cisco, с описанием особенностей работы коммутаторов серии cisco2950. Там я подробно изложу свою точку зрения, с соответствующими аргументами. И если у вас останутся вопросы, то мы сможем обсудить их в комментариях к той статье, так как это уже вопросы более специфические.
Не зря же в сети под сотню принт-серверов HP-шных. =)
А мороки никакой — тот же софт, тот же IP прописать.
Либо на клиентах, либо в DNS.
А клиенты настроить на DNS имя.
Ну только если выводить МФУ в другую подсеть в другом vlan-е…
А это можно сделать и без принт-сервера, т.к. клиентское ПО можно настроить по IP.
Мы рассматривали множество вариантов решения. И выводить МФУ в отдельный vlan, и в отдельную подсеть с маршрутизацией, и вырезать порты на на клиентах…
Но как это не странно самым оптимальным решением является все же именно настройка корректного времени.
Был поставлен эксперимент. В 18-00 все сотрудники уходят, выключая свои машины. Перезагрузка МФУ в 19-00 не дает никакого эффекта! Просто некому ответить на эти пакеты, а если кто и задержался на работе, то что там какие-то 200-300 пакетов?
Вот так! Все гениальное просто.
назвать cisco2950 — тупым свичом… у меня язык не поворачивается. да, не корпоративный уровень, но никак не тупая.(vlan тут не при чом)
открытые порты — а зачем закрывать порты в сети, которая находиться за множеством фаерволов? и опять таки это не имеет отношение к сетевому администрированию
не настроено что?!
1) это ПО должно быть на множестве клиентов в данной подсети(допустим распространить вирусом)
2) в данной подсети должно быть множество устройств, работающих с SNMP в комьюнити public
3) TC(Topology Change) — вызываны слабым железом. с одной стороны в сети может и не быть таких железок. с другой стороны вся сеть может быть построена только на них, и тогда…
4) есть один интересный момент, в дампе четко видно TTL=1, что не позволяет пакету покидать данную подсеть… а если IP.TTL = '255', то большому кораблю большое плавание! Но тут уже все зависит от настроек маршрутизации…
наверное определяющим является второй пункт.
ни разу не смотрел.
видимо стоит все же глянуть.
и проблема эта известная.
еще хуже то, что этот широковещательный домен размазан по 30+ коммутаторам и двум зданиям!
но увы, есть причины(от админов независящие), по которым ситуация остается неизменной и решение этих проблем отложено на неопределенный срок.
а проблем с производительностью на практике нет.