Можно-ли разбудить ноутбук Скайпом?

Зависит от конкретного функционала конкретного сетевого адаптера. А именно - по какому типу входящих TCP/IP пакетов он умеет просыпаться.

>Можно-ли разбудить ноутбук Скайпом?
Нет.

Можно разбудить только с помощью технологии Wake-on-Lan (сокр. WOL, см. Википедию). Причём ноут должен быть подключён к сети проводом, а не с помощью WiFi. Чтобы узнать поддерживается ли данная технология конкретно у вас - зайдите в свойства сетевого адаптера (вкладка "Дополнительно") и ищите вышеуказанные буквы.

Плюс если ноут находится за маршрутизатором, и хочется включить его через Интернет, то ещё потребуется настраивать маршрутизатор.

Er.DS писал(а)
>Можно-ли разбудить ноутбук Скайпом?
Нет.
Можно разбудить только с помощью технологии Wake-on-Lan (сокр. WOL, см. Википедию).

Вы не правы.
Это похоже на диалог:

- Можно купить в вашем баре пива?
- Нет. В нашем баре можно купить только спиртное.

Wake -on-LAN - это общее название технологии, позволяющей будить комп по определенному событию, связанному с сетевым адаптером. А уж что это конкретно за событие - это определяется конкретным сетевым адаптером и его способностями.
См. также technet.microsoft.com/en-us/library/ee617165(v=ws.10).aspx

ЗЫ. Через вай-фай ноут тоже можно разбудить, если что.

А скайп должен быть установлен на этом же ноуте?

Вообще в Win10 (и вроде в 8 тоже) теоретически может и можно. Там какую-то новую технологию суспенда придумали, ноут как-бы засуспенжен, но приложения, поддерживающие эту фичу, могут по прежнему ждать событий, например IM принимать сообщения и отображать уведомления на миниэкранчике, если у ноута есть отдельный миниэкран.

Во, нашёл, этот режим называется Always On или Connected StandBy. Видимо реализовано как-то таким образом что у приложений какой-то микрокод может продолжать работать в режиме суспенда, причём поддерживается это только определёнными моделями процессоров Intel.

www.umpcportal.com/2015/08/m...-tests-fix-tips/

Вот тоже интересно как бы что-то подобное реализовать.
Может маршрутизатор можно как-то научить посылать WOL-пакет компу при пролёте пакета с определёнными параметрами (порт, ip-адрес, ...)?
Хотя пока комп проснётся может уже и нужда-то отпадёт? На сколько у звонящего по скайпу терпения хватит?

Er1css0n писал(а)
Может маршрутизатор можно как-то научить посылать WOL-пакет компу при пролёте пакета с определёнными параметрами (порт, ip-адрес, ...)?

Всё уже давно придумано:
Wake Patterns . Wake patterns refer to network packet filters that determine if incoming network traffic should wake the computer. You can enable these patterns on the network adapter.

technet.microsoft.com/en-us/library/ee617165(v=ws.10).aspx

Если не ошибаюсь WoL работает только по проводу - т.к. электричество потребляемое картой получается из этого же провода (Ethernet).
Если включать комп по wi-fi то надо чтобы модуль wi-fi кушал электричество -> жор батареи или питания от сети. Возможно в меньших количествах.

Вот что гуглится - "Wake on Wireless LAN"
forum.ixbt.com/topic.cgi?id=4:113588
technet.microsoft.com/ru-ru/library/ee851581(v=ws.10).aspx

И говорят что заработало. Сам не пробовал - не знаю.

OLEn писал(а)
Если не ошибаюсь WoL работает только по проводу - т.к. электричество потребляемое картой получается из этого же провода (Ethernet).

Не совсем. Карточка питается от дежурного напряжения, подаваемого с БП на материнскую плату. Соотв-но, выходные цепи БП частично под напряжением.

Достаточно было бы завести "галку" вкл/выкл поддержку WiFi соединения в standby режиме, или отдельный энергосберегающий режим. Все это реализовано миллион лет тому назад для встроенных систем (телефоны, таблеты, IoT и т.д.), причем без по большому счету ненужных wake up pattern-ов. Просто включается фильтрация mcast/bcast пакетов, arp offload, offload известных ssid, настройки сканирования оных и т.д. Просыпаемся только по ucast пакетам (коим пакет от скайпа безусловно будет являться). Для прерывания можно использоваться in-band прерывания по шине, по которой адаптер общается с хостом, например через PCIe, а во встроенных системах для простоты обычно заводят отдельный gpio сигнальчик. Не совсем понятно, для чего MSFT нагородил паттерны?

А не будет ли бук просыпаться от любого юникастового пакета помимо скайпового? Може в паттернах от микрософта это как-то гибче реализовано? Плюс не надо лазить по разным местам для настройки. Всё в одном месте (да и не являются ли эти паттерны оболочкой над всем, что Вы предлагаете)?

Потом мне думается, что Ваш вариант, что микрософтный требует всё таки от компа большего ума (т.е. энергопотребления), чем в случае с WOL.

Все так. Но в этом случае будет универсальность и звонящему клиенту не нужно посылать никакие особые паттерны. Да, стэндбай режим будет не таким глубоким и просыпаться будем по каждому чиху (ucast-овому пакету), но почему то, что возможно и прекрасно работает даже на смарт-часах, питающихся от малюсенькой батарейки, или на телефоне, невозможно на компьютере? Возможно все дело в отсутствии возможности быстро засыпать, просыпаться в ОС от MSFT?

Collins писал(а)
Достаточно было бы завести "галку" вкл/выкл поддержку WiFi соединения

Речь про провод, при чем тут вай-фай?

> Не совсем понятно, для чего MSFT нагородил паттерны?
Паттерны заведены для того, что бы сетевая карта знала, на какой пакет ей просыпаться.

Спасибо, Кэп. Какая разница между проводным и беспроводным адаптером с точки зрения сетевого стэка L3 и выше и PM? Вот поэтому и привел в пример то, где все это давно работает, просто на таблетках нет разъема для сетевого кабеля. Просыпается не карта, а хост, который будится картой(адаптером) генерацией прерывания по ucast пакету или по патерну (в зависимости от реализации).

Collins писал(а)
Какая разница между проводным и беспроводным адаптером с точки зрения сетевого стэка L3 и выше и PM?

С точки зрения PM - существенная. Объяснять подробно или сам нагуглишь? Начать с того, что к стеку L3 и выше это вообще отношения не имеет - PM прозрачен для сетевого/транспортного уровней.

>Просыпается не карта, а хост, который будится картой(адаптером) генерацией прерывания
Спасибо, кэп (С)
Хост будится не генерацией прерывания, а поднятием сигнала WAKE#, ибо другого способа разбудить хост, находящийся в ACPI state S5 (soft-off) /S4 (hibernate) просто не существует, а из S3 хоть и можно (только не прерыванием, а сообщением - это разные вещи), но не рекомендуется.

Так вот, что бы карта знала, когда поднять WAKE#, в неё передается паттерн и дальше она тупо вылавливает его в полученных кадрах. Такой механизм универсален и позволяет будить хост хоть по арпу, хоть по пингу, хоть по пакету нетбиос, хоть по скайпу. Вопрос лишь в реализации этой функции драйвером.

С точки зрения PM для поддержания WLAN соединения (только для поддержания) требуется < 1mA/h. На фоне объема батарейки ты этого даже под микроскопом не увидишь. Это я тебе, голуба, говорю как эксперт, который потратил достаточно сил и времени на то, чтобы эти критерии удовлетворялись. Что касается пробуждения хоста, то в нормальных системах WiFi чип просто выставляет прерывание (это может быть как in-band прерывание через PCIe, PME event-ы, SDIO, прерывание через DAT-1 сигнал или любую другую шину, поддерживающую прерывание), так и ассерт простейшего сигнальчика (GPIO), в любом случае данное прерывание для процессора должно являться wakeup source-ом, и нормальные системы в состоянии пробудиться из самого глубокого энергосберегающего состояния достаточно быстро, обработать данное прерывание, обработать входящие данные, а дальше уже решать, уходить спать дальше или начинать проигрывание звонока скайпа, опять же все с оговоркой на нормальные системы, которые в состоянии быстро реагировать на внешние события.

>>Вопрос лишь в реализации этой функции драйвером.
Смешались люди, кони. Драйвер для реализации отлавливания пакетов, которые являются wakeup pattern-ом, вообще не используется, т.к. это функция FW, а драйвер в это самое время suspended и спит вместе с остальными компонентами хоста. Функция WLAN host driver-а и компонент более высокого уровня в данном случае ограничивается лишь конфигурацией фильтров пакетов/паттернов и доставкой этой информации до FW.

Collins писал(а)
С точки зрения PM для поддержания WLAN соединения (только для поддержания) требуется < 1mA/h.

Садись, два (с)
Поддержание WLAN-соединения это вообще ни о чём. Проблема в том, что трафик приходит закриптованный. А теперь подумай, и ответь:
1) кто будет его декриптовать несколько мегабит трафика ?
2) как это отразится на энергопотреблении?
Поэтому единственный вменяемый способ делать wake - по незашифрованным (т.е., management) пакетам. В этом существенная разница с проводным эзернетом.

>Драйвер для реализации отлавливания пакетов, которые являются wakeup pattern-ом, вообще не используется, т.к. это функция FW,

Меня потрясает твоя способность читать одно, а видеть другое. Для того, что бы карточка смогла нужный паттерн отловить, его надо сначала определить и самой карточке передать. Так вот это и делает драйвер, а все остальное уже дело техники.

>Функция WLAN host driver-а и компонент более высокого уровня в данном случае ограничивается лишь конфигурацией фильтров пакетов/паттернов и доставкой этой информации до FW

Спасибо, Адмирал Очевидность! Коллинз, ты всегда увидев дифф. уравнение начинаешь отвечать про 2 x 2?

>это может быть как in-band прерывание через PCIe, PME event-ы, SDIO, прерывание через DAT-1 сигнал или любую другую шину, поддерживающую прерывание), так и ассерт простейшего сигнальчика (GPIO)
In-band прерывание тебе не поможет, ибо CPU носта не тактуется и вообще может обесточен. GPIO и прочее не в тему, ибо их удел всякие встроенные системы а у нас речь идет конкретно о ПК. Поэтому имеем дело с PM event'ом, который к прерыванию, строго говоря, отношения не имеет.

А теперь вернемся к изначальному вопросу: после того, как ты немного нагуглил тему, тебе стало яснее "для чего MSFT нагородил паттерны" или надо объяснять дальше?

Дабы не расплываться мыслью по древу и не зафлуживать тему, вернемся к исходному тезису:

Collins писал(а)
Какая разница между проводным и беспроводным адаптером с точки зрения сетевого стэка L3 и выше и PM?

С т. зр. управления питанием разница заключается в том, что для пробуждения по заданному пакету с данными в случае с проводным адаптером мы находимся в режиме listen-only: карточка просто ищет нужный паттерн в полученных фреймах и по получении генерит wake-up event (как она это делает - инициированием ли шинного цикла MemWr по адресу FE30, поднятием ли ноги GPIO, опусканием ли WAKE# и т.д. - в данном контексте не принципиально), работает только PHY и немного MAC. CPU хоста (и сам хост) может быть в любом состоянии: Vcc подано/отсутствует, кэш сброшен, конвейер остановлен, опорная частота не подана и т.д., вплоть до физического изъятия (утрированно, разумеется). Это дает возможность пробуждения из любого ACPI state, включая soft-off.

В случае беспроводного адаптера мы должны физически расшифровывать все входящие фреймы, плюс к этому нести все накладные расходы по поддержанию соединения (периодическая смена ключей, поддержание ассоциации с БС и т.д.), а это требует активности со стороны CPU хоста. Следовательно, такой wake может вывести хост только из режима stand-by и в принципе не будет работать с hibernate или soft-off, что делает его малоценным и не подходит под ТЗ, озвученное топик-стартером в заглавном посте. Именно этим фактом и было вызвано мое замечание "речь про провод, при чем тут вай-фай".
Я ответил на твой вопрос?

Именно поэтому я подчеркнул, что только для поддержания соединения, т.е. просыпание на нный бикон фрейм и отправка L2 keep alive packets без вмешательства хоста. На все это требуется меньше mA/h. Продление лиза IP, rekeying etc, это добавит еще столько-то в зависимости от конфигурации. Можно просыпаться раз в 15 минут, а можно раз в пятилетку. В любом случае, во встроенных системах, способных быстро реагировать на прерывания и засыпать, сигналом к пробуждению служит ucast tcp пакеты. И все прекрасно работает даже на батареях в сотни раз меньше компьютерных. Основная проблема для компьютера - неповоротливость Windows. Отсюда и специальные паттерны для пробуждения, чтобы лишний раз не тревожить неповоротливый хост.

Ребят, вот честно - я даже читать не стал.
Вроде буквы знакомые, а что написано - не понятно.
Так что в итоге-то? Можно-ли разбудить по проводу/воздуху Скайпом?
Не в теории, а в суровой реальности?

А как же по314здеть? На самом деле мне с прошлой недели эта тема очень интересна, т.к. нужно решать, по какому событию будет просыпаться устройство совершенно нового типа. И в ходе раздумий пришел к выводу, что хреновый будет из меня инженер (точнее из тех, кто занимается PM в целом, т.к. с моей стороны проблем не должно возникнуть), если не смогу обойтись без паттернов, ограничившись лишь TCP ucast пакетами. У меня на раздумье еще есть 2-3 недели.

Saradon писал(а)
Так что в итоге-то? Можно-ли разбудить по проводу/воздуху Скайпом?

Можно, при условии что:
1) драйвер вашей проводной сетевой карты имеет фичу Wake-on-Pattern (у Интела, вроде, есть такое)
2) вы четко можете выделить паттерн, который идет при звонке (не проверял).
По п. 1 можешь задать вопрос в подержку вендора ноутбука.

По п.1 - попробую узнать позже - ноут ещё в пути.
По п.2 - опять слова какие-то непонятные...
Теоретически, звонящий будет только один и его можно надрессировать перед звонком жмякать какой-нито ярлычок, который тут будет по сетке будить этот ноут.

Долго-ли, коротко-ли приехал ноут.
Да не простой, а чуднОй.
HP Stream 11.
Хорош, зараза.
Слабенький, но абсолютно бесшумный.
Сейчас пытаюсь добиться от него русской речи вместо испанской и Win 10 вместо 8.1
В UEFI по поводу загрузки по сети есь вот что --->

При чём тут загрузка? Ищите Wake Up. И то, только для включения.
Просыпание в ОС.