Comments 67
правильно ли понял, что ноутбук с линуксом если подключить его эзернетом к сети, то из него можно сделать AP? А ubuntu подходит?
Правильно. Из линя не только можно ap сделать, но и чпу, систему управления атомной станции, бортовой компьютер и т.п., но и… микроволновку.)))
Можно. Но зачем?
AP — самое то.
ЧПУ — избыточно, но пойдет.
Система управления АЭС — ни в коем случае, здесь нужно что-то заточенное и реалтаймовое. QNX какой-нибудь, например.
Бортовой компьютер — избыточно, но пойдет.
Микроволновка — из пушки по воробьям. Разве что это будет телевизорошкафоящик с функцией микроволновки.
AP — самое то.
ЧПУ — избыточно, но пойдет.
Система управления АЭС — ни в коем случае, здесь нужно что-то заточенное и реалтаймовое. QNX какой-нибудь, например.
Бортовой компьютер — избыточно, но пойдет.
Микроволновка — из пушки по воробьям. Разве что это будет телевизорошкафоящик с функцией микроволновки.
linux cnc-ubuntu по сути. ЧПУ.
Linux уже давно умеет в режиме реального времени работать. Соответствующие опции в ядре.
МКС на лине!!!
Но можно-же.)))
Linux уже давно умеет в режиме реального времени работать. Соответствующие опции в ядре.
МКС на лине!!!
Но можно-же.)))
Linux? В реальном времени? Да вы шутите.
То, что есть в ядре (помню, когда-то еще был rt патчсет, сейчас он наверное уже влит в ядро) — лишь попытка получить более-менее приближенное к реальному времени ядро.
То, что есть в ядре (помню, когда-то еще был rt патчсет, сейчас он наверное уже влит в ядро) — лишь попытка получить более-менее приближенное к реальному времени ядро.
не влит
Была ещё попытка сделать Completely Fair Scheduler, которую в 2.6 почему-то не приняли. У меня с этим патчем сразу же пропали задержки при проигрывании видео и прочая неприятная ерунда.
ЧПУ это круто, но там система вида «сдвинуть сверло туда-то», и если сверло задержится хоть секунду в каком-то неподвижном положении, пока кто-то свапится и т.п., ничего страшного не произойдёт. По идее на 3d печать уже может негативно влиять.
ЧПУ это круто, но там система вида «сдвинуть сверло туда-то», и если сверло задержится хоть секунду в каком-то неподвижном положении, пока кто-то свапится и т.п., ничего страшного не произойдёт. По идее на 3d печать уже может негативно влиять.
сначала нужно изучить офсайт призводителя сетевой карты, не все они умеют мастер режим.
Linux вообще друг человека =) И да, Ubuntu отлично подойдёт, нужно будет лишь использовать sudo — в моих примерах подразумевается наличие прав рута.
В свежих Gnome shell и тестовой плазме это можно сделать и без ковыряний с конфигами.
Эта опция не гном-шела или плазмы, это часть network-manager. Только вот есть нюанс. Точка доступа создаваемая таким образом не видна большинству мобильных и планшетов, в причины вникать не стал, завел hostap
Я и не говорил обратного, просто заюзать эту опцию из графического интерфейса можно только там
Видимо, это AD-HOC. Скажу сразу — я даже не рассматривал эту опцию, поскольку, как по мне, это подходит лишь для быстрого поднятия беспроводной связи между парой-тройкой ноутов на коленке, стабильность тоже так себе (использовал в своё время AD-HOC, встроенный в Windows XP и W7). Именно отсутствие поддержки на многих устройствах и не радует. Так что — лучше повозиться, но потом не жалеть о том, что не во всех случаях подходит, к hostapd подключается всё, что ловит сигнал.
Осмелюсь напомнить:
habrahabr.ru/post/122876/
habrahabr.ru/post/122876/
К слову, wpa_supplicant с некоторых пор сам умеет поднимать точку доступа, т.е. без hostapd. Он, конечно, простой, и фич там немного, может кому интересно будет. И, кстати, NetworkManager тоже может создавать точку доступа, как раз через wpa_supplicant, и сразу настраивать NAT и dnsmasq, и все это с gui.
Сохраняем и перезапускаем наш сетевой интерфейс, на котором настроен DHCP:Неверно.
ifconfig интерфейс down ifconfig интерфейс up
ifconfig «опускает» или «поднимает» лишь сам интерфейс, Вам же нужно его переконфигурировать. Потому использовать надо ifup и ifdown.Хм, спасибо. До этого считал, что ifup и ifdown — всего лишь алиасы для быстрого запуска. Пойду почитаю ман.
Ну так маны нужно читать до того, как хауту писать.
Ну так все команды не перепроверишь и не учтёшь, к сожалению.
А надо! Или не надо писать такие «статьи».
А что, если статья допускает ошибку в двух похожих командах, даже из прочтения мануалов по которым не всегда можно уловить разницу между ними, то это уже «статья»?
Между двумя командами есть принципиальная разница. Их невозможно спутать, потому что они делают совершенно разные вещи. И ошибок у Вас не две, а гораздо больше.
А судя по Вашему комментарию четыре абзаца ниже, это не просто «статья», а писанина воинствующе необразованного человека, который своим незнанием гордится. Уж извините, но Вы сами напросились.
А судя по Вашему комментарию четыре абзаца ниже, это не просто «статья», а писанина воинствующе необразованного человека, который своим незнанием гордится. Уж извините, но Вы сами напросились.
элементарно проверишь, если их два десятка
ещё к этому можно добавить, что уже пора бы использовать нативное линуксвое апи «netlink» для работы с сетью в виде пакета iproute2, а не эти ваши ifconfigги.
Вау. А не будет ли оверкиллом использовать это там, где по сути достаточно двух команд?
В смысле, оверкиллом? Вы в курсе, что именно делает утилита ip?
ip link eth0 set up, ip addr add 192.168.0.5/24 dev eth0, ip route add default via 192.168.0.1 — какой оверкилл? Кроме того, здесь вполе конкретно разделено поднятие второго уровня (ip link set eth0 up) и третьего (ip addr add, ip route add). Это прямолинейный путь решения, если потом использовать интерфейс в мосте или резать его на vlanы. Для меня всегда наоборот было загадкой, почему ifconfig не различает эти понятия.
ip link eth0 set up, ip addr add 192.168.0.5/24 dev eth0, ip route add default via 192.168.0.1 — какой оверкилл? Кроме того, здесь вполе конкретно разделено поднятие второго уровня (ip link set eth0 up) и третьего (ip addr add, ip route add). Это прямолинейный путь решения, если потом использовать интерфейс в мосте или резать его на vlanы. Для меня всегда наоборот было загадкой, почему ifconfig не различает эти понятия.
Ну, для некоторых вещей ifconfig удобнее всё-таки… В общем, это уже не так страшно.
Например, для каких?
Не, я серьёзно, ifconfig морально устарел и от его использования уже лет десять как пора отказываться. Мало того, что он и половины возможностей линукса не даст использовать, так и пользовательский интерфейс у него ужасен. Вам нравится вбивать маски вида 255.255.255.248? Я предпочитаю писать /29.
Не, я серьёзно, ifconfig морально устарел и от его использования уже лет десять как пора отказываться. Мало того, что он и половины возможностей линукса не даст использовать, так и пользовательский интерфейс у него ужасен. Вам нравится вбивать маски вида 255.255.255.248? Я предпочитаю писать /29.
Например, у него несколько удобнее сгруппированы параметры в выводе — читабельность повыше, чем у iproute, да и всё в одном месте. А удобнее в нём менять MTU на интерфейс, например, да и прочие параметры по одиночке — командная строка получается короче и немного очевиднее.
Ну вопрос удобства очень хочется оспорить… я вывод ip читаю гораздо легче и быстрее, чем ifconfig, route и т. д. — он более человеко-читабелен. А у ifconfig действительно всё в одном месте, в нашей стране вообще всё через это место. Но тут ладно, дело вкуса
Но почему ip addr мне покажет все IP4-адреса, навешанные на интерфейс, ifconfig — только один из них? А, предлагаете создавать алиасы для других адресов? Если их и так интерфейсов десяток, тут алиасы осложнят и запутают дело.
Но почему ip addr мне покажет все IP4-адреса, навешанные на интерфейс, ifconfig — только один из них? А, предлагаете создавать алиасы для других адресов? Если их и так интерфейсов десяток, тут алиасы осложнят и запутают дело.
Кстати, ifconfig поддерживает запись в стиле /29.
А ещё чушь написана про resolv.conf и dhclient. Если так нужно выключить обновление resolv.conf, так это делается в настройках dhclient. Или ставится пакет resolvconf, а потом нужные адреса добавляются туда с высшим приоритетом.
И да, сносить дефолтный конфиг dnsmasq — не самая хорошая идея. Если бы Вы его не снесли, Вы бы узнали, что dnsmasq-у можно указать, какие DNS-серверы использовать. Более того, там можно их тонко настроить.
А вообще, стиль написания напоминает приём у «квалифицированного врача»: болит голова — долой её с плеч. Ноги чешутся? Ампутировать!
И да, сносить дефолтный конфиг dnsmasq — не самая хорошая идея. Если бы Вы его не снесли, Вы бы узнали, что dnsmasq-у можно указать, какие DNS-серверы использовать. Более того, там можно их тонко настроить.
А вообще, стиль написания напоминает приём у «квалифицированного врача»: болит голова — долой её с плеч. Ноги чешутся? Ампутировать!
Заблокировать файл — один из путей достигнуть цели, и никто не запрещает его использовать. Да, никто также не запрещает указать это в настройках dhclient — но разницы-то по настоящему нет. Или, по-вашему, есть?
Да, спасибо, эту опцию в дефолтном конфиге я уже видел. Если её не указывать, довольно умный в плане опций dnsmasq, насколько я помню, берёт сервера из resolv.conf. А resolv.conf — файл, который предназначен для того, чтобы хранить названия DNS-серверов, используемых системой… Что он, внезапно, и делает, храня там 8.8.8.8, которые мы бы могли указать в конфиге dnsmasq… Но зачем, если есть resolv.conf? В который можно закинуть эти сервера и просто-напросто удостовериться, что не нужно будет обрубать лапы каждой программе, которая захочет изменить resolv.conf. Там просто нет смысла его менять, честно-честно.
Да, а ещё в resolv.conf можно указать localhost, где у нас dnsmasq, а ему же приказать брать серверы из ещё одного файла. Так тоже можно, да. Путей в Linux очень и очень много, честно говоря, сама идеология Linux об этом прямым текстом говорит.
Ну так вот, пожалуйста, приведите примеры, почему же блокировать файл волей администратора, который знает, что содержимое этого файла менять просто ну не надо — бред. И почему DNS-сервера, захардкоженные в /etc/dnsmasq.conf, лучше, чем те же сервера в /etc/resolv.conf, хотя, по идее — им нужно быть в последнем.
Да, спасибо, эту опцию в дефолтном конфиге я уже видел. Если её не указывать, довольно умный в плане опций dnsmasq, насколько я помню, берёт сервера из resolv.conf. А resolv.conf — файл, который предназначен для того, чтобы хранить названия DNS-серверов, используемых системой… Что он, внезапно, и делает, храня там 8.8.8.8, которые мы бы могли указать в конфиге dnsmasq… Но зачем, если есть resolv.conf? В который можно закинуть эти сервера и просто-напросто удостовериться, что не нужно будет обрубать лапы каждой программе, которая захочет изменить resolv.conf. Там просто нет смысла его менять, честно-честно.
Да, а ещё в resolv.conf можно указать localhost, где у нас dnsmasq, а ему же приказать брать серверы из ещё одного файла. Так тоже можно, да. Путей в Linux очень и очень много, честно говоря, сама идеология Linux об этом прямым текстом говорит.
Ну так вот, пожалуйста, приведите примеры, почему же блокировать файл волей администратора, который знает, что содержимое этого файла менять просто ну не надо — бред. И почему DNS-сервера, захардкоженные в /etc/dnsmasq.conf, лучше, чем те же сервера в /etc/resolv.conf, хотя, по идее — им нужно быть в последнем.
Ну, примеры будут? Мне же самому выгодно пополнить свои знания, причём, по-видимому, заведомо неверные, поэтому и спрашиваю.
Ампутация головы излечит головную боль, причём навсегда. Будем так всех лечить, да?
Вы настолько неправы, что я даже не уверен, что мне хватит терпения Вам это разъяснить.
Вы настолько неправы, что я даже не уверен, что мне хватит терпения Вам это разъяснить.
Извините, но уверенность в стиле «Вы настолько неправы, я даже объяснить не смогу» как-то не является аргументом. Серьёзно — Вы производите впечатление человека, который заучил один путь и следует ему, всячески порицая другой, при этом не приводя ни одного аргумента кроме дважды повторённого сравнения, которое, на мой взгляд, притянуто за уши. Раз уж нельзя что-то делать, объясните, прошу.
— Почему блокировать файл от записи плохо?
— Почему системный администратор не может заблокировать от записи файл, который не должен быть перезаписан? dhclient поперхнётся? Уверяю Вас, работает нормально в разных сетях, просто везде используется один и тот же DNS — Гугловский.
— В чём минусы такого подхода?
Понимаете, можно решить всё не перезаписью, полностью согласен. Но зачем? В чём плюс? Минусы реально никто не перечислил — они все справа от моих комментариев, но объяснений нет. Печально. Да, я упрямый, но признавать недоказанные ошибки не вижу смысла.
There is no «one true way» to do anything. Вы уж простите, но это действительно так.
— Почему блокировать файл от записи плохо?
— Почему системный администратор не может заблокировать от записи файл, который не должен быть перезаписан? dhclient поперхнётся? Уверяю Вас, работает нормально в разных сетях, просто везде используется один и тот же DNS — Гугловский.
— В чём минусы такого подхода?
Понимаете, можно решить всё не перезаписью, полностью согласен. Но зачем? В чём плюс? Минусы реально никто не перечислил — они все справа от моих комментариев, но объяснений нет. Печально. Да, я упрямый, но признавать недоказанные ошибки не вижу смысла.
There is no «one true way» to do anything. Вы уж простите, но это действительно так.
Это не аргумент. Мне просто жалко собственного времени. Если Вы думаете, что мне больше нечего делать, кроме как с жуткой головной болью расписывать Вам элементарные вещи, то Вы сильно заблуждаетесь.
Знаете, да, есть много разных способов добиться результата. Тем не менее, далеко не все из них хоть сколько-нибудь приемлемы. Более того, раз уж Вы так уверены в своей правоте, Вам не должно составить ни малейшего труда пояснить, почему Вы считаете именно Ваш способ допустимым или правильным.
Знаете, да, есть много разных способов добиться результата. Тем не менее, далеко не все из них хоть сколько-нибудь приемлемы. Более того, раз уж Вы так уверены в своей правоте, Вам не должно составить ни малейшего труда пояснить, почему Вы считаете именно Ваш способ допустимым или правильным.
Если вы не имеете желания доказывать — почему утверждаете в стиле «Статья того не стоит, вот это ошибочно, но я не докажу, почему»?
Так. Краткое описание моего способа:
dnsmasq берёт DNS-сервера из resolv.conf
Сервера прописаны статичные, т.е. всегда используются одни и те же, признанные надёжными. Никто не запрещает, плюс — во всех сетях гарантирована работа DNS, а то он имеет свойство падать на дешёвых роутерах, к которым я иногда подключаюсь ;-)
Проблема — при получении информации от DHCP-сервера dhclient также перезаписывает resolv.conf. Нам это не надо — у нас DNS прописан навечно один и тот же.
Есть 3 варианта избежать перезаписи файла, не отключая dhclient:
1) Отредактировать конфиг dhclient. В нём для отключения перезаписи файла нужно прописать те же статические адреса, что и в resolv.conf. Плюсы — проблема решена. Минусы — если потребуется изменить статический DNS на OpenDNS, к примеру, придётся вспоминать, что я раньше конфигурировал и как именно. resolv.conf немножечко так теряет своё значение — место хранения адресов DNS-серверов. Всё потому, что адреса DNS по факту хранятся в каком-то другом файле, а это уже затрудняет дальнейшую конфигурацию.
2) Отключить у dhclient функцию перезаписи resolv.conf. Да, такая функция имеется. Плюсы — такие же, как у третьего способа, который я и использовал (блокировка файла). Минусов на два больше. Первый — это то, что файл всё равно может быть перезаписан кем-то ещё, хоть это и нежелательно.
Почему не описал в статье? Вот и второй минус этого способа. Есть одно правило, которое необходимо соблюдать, когда пишешь статью. Она должна быть удобочитаемой, у статьи есть конечная цель. Эта цель — фраза «Всё настроено». Отходить от пути к этой цели нужно очень осторожно и маленькими шагами — иначе рискуешь четверть статьи посвятить тонкой настройке dhclient. Это, может, и хорошо, но в статье нарушается баланс подробность-удобочитаемость. И редактирование файлов с функциями dhclient — это та вещь, которую я, как автор статьи, посчитал неважной для читателя. Ведь читателю от этой статьи нужна инструкция по настройке точки доступа, а не dhclient, иначе у статьи был бы другой заголовок, не думаете?
3) Блокировка файла. Плюсы — 1) цель достигнута 2) список серверов вообще никто не перезапишет 3) тем более dhclient 4) всего одна консольная команда. Минусы — dhclient поругается в консоль, если его вызвать ручками. Свои основные функции он по-прежнему выполняет, не выполняет только не нужную нам.
Всё, пожалуй. Если не будет достойного комментария — я лучше перестану отвечать, у меня на очереди ещё не одна статья. Почему сейчас отвечаю? Всё просто. Именно по комментариям читатели определяют, какие рекомендации верны, а какие — нет. Это моя статья, и я написал её не просто так, а чтобы создать полноценный материал, способный помочь в настройке. И именно я, как автор, ответственный за написанное, буду доказывать, что статья моя — не результат переработки пищи экземпляром Canis Lupus, а то, что действительно может помочь в настройке. И именно я поблагодарил Вас за поправку к статье (ifup/ifconfig) — опять же, мне самому выгодно, чтобы статья была хорошей. И именно я буду объяснять что «так на самом деле можно» — это моя статья, и моё мнение, а я стараюсь всегда обосновывать своё мнение — а необоснованная критика ничего хорошего статье априори не несёт.
Так. Краткое описание моего способа:
dnsmasq берёт DNS-сервера из resolv.conf
Сервера прописаны статичные, т.е. всегда используются одни и те же, признанные надёжными. Никто не запрещает, плюс — во всех сетях гарантирована работа DNS, а то он имеет свойство падать на дешёвых роутерах, к которым я иногда подключаюсь ;-)
Проблема — при получении информации от DHCP-сервера dhclient также перезаписывает resolv.conf. Нам это не надо — у нас DNS прописан навечно один и тот же.
Есть 3 варианта избежать перезаписи файла, не отключая dhclient:
1) Отредактировать конфиг dhclient. В нём для отключения перезаписи файла нужно прописать те же статические адреса, что и в resolv.conf. Плюсы — проблема решена. Минусы — если потребуется изменить статический DNS на OpenDNS, к примеру, придётся вспоминать, что я раньше конфигурировал и как именно. resolv.conf немножечко так теряет своё значение — место хранения адресов DNS-серверов. Всё потому, что адреса DNS по факту хранятся в каком-то другом файле, а это уже затрудняет дальнейшую конфигурацию.
2) Отключить у dhclient функцию перезаписи resolv.conf. Да, такая функция имеется. Плюсы — такие же, как у третьего способа, который я и использовал (блокировка файла). Минусов на два больше. Первый — это то, что файл всё равно может быть перезаписан кем-то ещё, хоть это и нежелательно.
Почему не описал в статье? Вот и второй минус этого способа. Есть одно правило, которое необходимо соблюдать, когда пишешь статью. Она должна быть удобочитаемой, у статьи есть конечная цель. Эта цель — фраза «Всё настроено». Отходить от пути к этой цели нужно очень осторожно и маленькими шагами — иначе рискуешь четверть статьи посвятить тонкой настройке dhclient. Это, может, и хорошо, но в статье нарушается баланс подробность-удобочитаемость. И редактирование файлов с функциями dhclient — это та вещь, которую я, как автор статьи, посчитал неважной для читателя. Ведь читателю от этой статьи нужна инструкция по настройке точки доступа, а не dhclient, иначе у статьи был бы другой заголовок, не думаете?
3) Блокировка файла. Плюсы — 1) цель достигнута 2) список серверов вообще никто не перезапишет 3) тем более dhclient 4) всего одна консольная команда. Минусы — dhclient поругается в консоль, если его вызвать ручками. Свои основные функции он по-прежнему выполняет, не выполняет только не нужную нам.
Всё, пожалуй. Если не будет достойного комментария — я лучше перестану отвечать, у меня на очереди ещё не одна статья. Почему сейчас отвечаю? Всё просто. Именно по комментариям читатели определяют, какие рекомендации верны, а какие — нет. Это моя статья, и я написал её не просто так, а чтобы создать полноценный материал, способный помочь в настройке. И именно я, как автор, ответственный за написанное, буду доказывать, что статья моя — не результат переработки пищи экземпляром Canis Lupus, а то, что действительно может помочь в настройке. И именно я поблагодарил Вас за поправку к статье (ifup/ifconfig) — опять же, мне самому выгодно, чтобы статья была хорошей. И именно я буду объяснять что «так на самом деле можно» — это моя статья, и моё мнение, а я стараюсь всегда обосновывать своё мнение — а необоснованная критика ничего хорошего статье априори не несёт.
Всё проблемы у Вас от неправильной постановки задачи. Вам не нужно избегать перезаписи resolv.conf как такового. Вам нужно, чтобы использовался DNS-сервер от гугла (сомнительная сама по себе цель, ну да ладно). От неправильной постановки задачи идёт неправильное её решение.
1) Задача поставлена правильно. Нужно, чтобы DNS сервера хранились в resolv.conf (их каноничное место) и чтобы использовался статический DNS-сервер (не имеет значения, какой). Цель достигнута.
2) Аргументов до сих пор нет — всего хорошего. У меня тоже, знаете ли, есть цели и свободное время. Сейчас моя позиция уже разъяснена и больше объяснять я не вижу смысла.
Удачного Вам дня! Надеюсь, что нам обоим этот спор как-либо пойдёт на пользу.
2) Аргументов до сих пор нет — всего хорошего. У меня тоже, знаете ли, есть цели и свободное время. Сейчас моя позиция уже разъяснена и больше объяснять я не вижу смысла.
Удачного Вам дня! Надеюсь, что нам обоим этот спор как-либо пойдёт на пользу.
Как я уже и сказал, Вы — воинствующий невежда, отстаивающий свою неправоту с пеной у рта. Но не волнуйтесь, это проходит. Со временем. Обычно.
Вообще-то все вменяемые дистрибутивы позволяют задать какой-нибудь resolv.conf.head, который всегда будет в начале resolfv.conf, чем бы он не генерировался. А ещё есть такая штука как resolvconf.d и сервис, который управляет его содержимым и взаимодействием с файлом resolv.conf. Ну, как раз сделано специально для тех, кому не нравится перезапись resolv.conf.
Но вы действительно вместо того, как разобраться с этим, принялись блокировать перезапись файла и доказываете, что это правильно.
Такие блокировки потом приводят к проблемам. А некоторые дистрибутивы, опять же, умеют их автоматически снимать, так что ваш метод вообще не работоспособен.
Но вы действительно вместо того, как разобраться с этим, принялись блокировать перезапись файла и доказываете, что это правильно.
Такие блокировки потом приводят к проблемам. А некоторые дистрибутивы, опять же, умеют их автоматически снимать, так что ваш метод вообще не работоспособен.
habrahabr.ru/post/89420/ я уже писал такую статью. Правда она немного устарела.
Все через это проходят :-)
habrahabr.ru/post/127879/
habrahabr.ru/post/127879/
Для лучшей производительности рекомендуются 1, 6 или 11 канал
Для лучшей производительности рекомендуется тот канал, где меньше всего соседей ;-)
Это-то конечно =) Но логика тут простая — все и так либо на крайних каналах. либо на центральном — распределение такое, чтобы уменьшить негативное взаимодействие сигнала AP на разных каналах. И если поставить точку где-то между 1 и 6, то на сигнал нашей точки будут влиять как станции из канала 1, так и станции из канала 6, так же и с 6 и 11. Поправьте меня, если что.
Мне кажется, что если делать уж доступ через линукс — то уже сразу с пользователями и паролями (решений несколько). Остальное лучше через дешевые AP (там как правило и сигнал качественнее, и энергопотребление ниже, да и еще несколько бенефитов от апаратной реализации некоторых вещей).
Может напишите подобное (сам когда то пару раз делал — приходилось пол часика погуглить).?
Может напишите подобное (сам когда то пару раз делал — приходилось пол часика погуглить).?
К слову, я сам сейчас думаю о том, чтобы освоить Sputnik или что-то подобное. А если буду осваивать — обязательно напишу статью. К тому же — есть идея, где это можно применить с пользой в ближайшее время. А ноут — лишь одна из альтернатив, те же дешёвые AP элементарно не выдержат многих вещей и тоже не имеют многих аппаратных плюшек нетбука. К тому же я буквально сейчас работаю над тем, чтобы встроить гнездо RP-SMA для антенны в корпус ноута, сегодня буду паять переходник IPX-RP SMA и сверлить корпус ноута, ну и карточку беспроводную думаю другую поставить =)
Спасибо за статью.
Кстати, можно делать не так:
Результат один, но второй вариант короче :)
Кстати, можно делать не так:
$ echo "">/etc/dnsmasq.conf $ > /etc/dnsmasq.conf Результат один, но второй вариант короче :)
А как можно сделать скрытую точку?
А все-таки, огласите список железа, на котором это хозяйство поднято, особенно WiFi-карточку.
Sign up to leave a comment.
Беспроводная точка доступа, используя Linux