RU2818971C2

RU2818971C2 - Отчет о состоянии предыдущего соединения

Info

Publication number: RU2818971C2
Application number: RU2021126748A
Authority: RU
Inventors: Йоханнес Арнольдус Корнелис БЕРНСЕН
Original assignee: Конинклейке Филипс Н.В.
Priority date: 2019-02-11
Filing date: 2020-02-06
Publication date: 2024-05-08

Abstract

Изобретение относится к области беспроводной связи. Техническим результатом является успешное и более быстрое присоединение устройства связи, запрашивающего регистрацию в беспроводной сети связи, к беспроводной сети связи. Способ конфигурирования устройства (5) связи без пользовательского интерфейса, запрашивающего регистрацию в беспроводной сети связи, включает: выполнение протокола конфигурирования устройством (5) связи без пользовательского интерфейса, отправку устройством (5) связи без пользовательского интерфейса конфигурирующему устройству (9) связи сообщения, содержащего указание состояния предыдущей попытки конфигурирования и указание причины, если предыдущая попытка конфигурирования не удалась, и выполнение конфигурирующим устройством (9) связи прерывания конфигурирования, если конфигурирование прошло успешно, или отображения в пользовательском интерфейсе информации о том, что предыдущая попытка не удалась. 3 н. и 12 з.п. ф-лы, 4 ил.

Description

ОБЛАСТЬ ТЕХНИКИ

Настоящее изобретение относится к устройствам и способам использования в беспроводных сетях, в частности, в сетях, удовлетворяющих семейству стандартов IEEE 802.11.

УРОВЕНЬ ТЕХНИКИ

На Фиг. 1 представлена беспроводная сеть 1, которая содержит первое устройство 2 и другое устройство 3. Первое устройство 2 может иметь центральную функцию и быть таким, как точка доступа (Access Point, AP), концентратор или шлюзовое устройство. Для простоты первое устройство 2 будет далее именоваться AP, хотя в действительности возможны устройства других типов. Пользователь (не показан) желает добавить еще два устройства к сети 1, а именно, сложное устройство 4 (представленное здесь как компьютер) и простое устройство 5 (представленное здесь как зубная щетка). Устройства, такие как простое устройство 5, часто не имеют никакого реального пользовательского интерфейса (ПИ), кроме, возможно, светового индикатора, и, соответственно, их часто называют «безголовыми» устройствами. AP 2 имеет процессор 6, а простое устройство 5 имеет микроконтроллер, а также маленькую энергонезависимую память 7 и кнопку 8, с помощью которой можно выполнить сброс простого устройства 5. Имеется также третье устройство 9.

Некоторые стандарты создания беспроводных сетей допускают конфигурирование одним устройством другого для установления соединения и обмена данными. Это делает задачу добавления или регистрации нового устройства в сети менее обременительной, поскольку пользователю больше не нужно вводить данные вручную.

Устройства, которые имеют пользовательский интерфейс, такие как сложное устройство 5, могут показывать состояние соединения с AP после конфигурирования и в случае возникновения проблемы, например, если устройство не может «найти» AP (или другое устройство с которым нужно соединиться). Однако, в случае простых (безголовых) устройств единственным способом, позволяющим пользователю наблюдать за успешным соединением, является просмотр пользовательского интерфейса точки доступа (AP), концентратора или шлюза. В случае безголовых устройств, т.е. устройств без пользовательского интерфейса, дело обстоит иначе. Если после конфигурирования эти устройства сталкиваются с проблемой при попытке соединиться с сетью, для соединения с которой их конфигурировали, пользователь не знает, что пошло не так, и может не понять этого, пока не проверит пользовательский интерфейс точки доступа.

В документе US 2017/257819 обсуждается предоставление безголового устройства, но не учитываются предыдущие попытки соединения.

РАСКРЫТИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ

Таким образом, предлагается способ конфигурирования "устройства-заявителя" (enrollee device) для связи в беспроводной сети, включающий выполнение протокола конфигурирования и во время исполнения протокола конфигурирования отправку устройством-заявителем сообщения, содержащего указание состояния предыдущей попытки конфигурирования.

После этого конфигурирующее устройство, принимающее состояние предыдущей попытки конфигурирования, может действовать в соответствии с ним. Например, оно может прервать конфигурирование, если в этом нет необходимости, или информировать пользователя о том, что предыдущая попытка не удалась. Информация, предоставляемая пользователю, позволит пользователю понять, почему устройству не удалось соединиться с требуемой сетью, и, возможно, уведомит его о том, что устройство не соединено. Это особенно важно, когда устройство, которое нужно присоединить к сети, является простым или безголовым устройством, у которого нет средств для непосредственного информирования пользователя. Такое устройство может казаться сконфигурированным, но не может присоединиться. Пользователь может понимать, что устройству не удалось присоединиться, не знать причину или, что еще хуже, узнать об этом только спустя некоторое время. Наличие такого своевременного указания могло бы сэкономить пользователю много времени и усилий.

В соответствии с вариантом реализации сообщение является одним из сообщения запроса на проверку подлинности, сообщения ответа по проверке подлинности, сообщения подтверждения проверки подлинности или сообщения запроса на конфигурацию. Обмен этими сообщениями происходит между конфигурирующим устройством и устройством, подлежащим регистрации во время процесса конфигурирования. За счет включения указания в одно или более из этих сообщений безголовое устройство в соответствии с настоящим вариантом реализации способно автоматически и без специального рассмотрения пользователем конфигурирующего устройства в соответствии с настоящим изобретением информировать о результате предыдущей попытки.

В соответствии с вариантом реализации конфигурирование является частью установления связи между устройством-Заявителем и другим устройством в беспроводной сети.

В соответствии с вариантом реализации указание содержит информацию по меньшей мере об одном из результата предыдущей попытки конфигурирования, выполненного в рамках предыдущей попытки конфигурировании действия, идентификатора сети и указания того, возможно ли повторное выполнение конфигурирования, для которого была предпринята предыдущая попытка конфигурирования, без выполнения сброса. Имея результат предыдущей попытки, конфигурирующее устройство может решить, какого порядка действий придерживаться при конфигурировании, и указать результат пользователю. Имея идентификатор сети, конфигурирующее устройство может определить для устройства, которое не может соединиться, но, тем не менее, завершило конфигурирование, причину неудачи соединения.

В соответствии с вариантом реализации прием сообщения, содержащего указание на успешную предыдущую попытку конфигурирования, приводит к прекращению протокола конфигурирования и избежанию тем самым бесполезного и потенциально проблематичного вызывания попытки повторного конфигурирования.

В соответствии с вариантом реализации прием сообщения, содержащего указание на предыдущую попытку конфигурирования, приводит к отображению принимающим устройством соответствующей информации в пользовательском интерфейсе и, таким образом, информированию пользователя о причине проблем с соединением.

В соответствии с вариантом реализации указание содержится в сегменте сообщения, который не зашифрован. Это может уменьшить вычислительную нагрузку на Конфигуратора за счет безопасности сети.

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

В соответствии с еще одним аспектом предложено устройство-Заявитель, выполненное с возможностью связи в беспроводной сети и сконфигурированное для участия в протоколе конфигурирования с устройством-Конфигуратором, причем протокол конфигурирования выполнен с возможностью конфигурирования устройства для связи в беспроводной сети и сохранения указания относительно предыдущей попытки конфигурировать устройство. Благодаря сохранению результата предыдущей попытки устройство-Заявитель может при новой попытке конфигурировать его предоставить информацию, чтобы пользователь мог быть проинформирован об этом результате.

В соответствии с вариантом реализации устройство-Заявитель выполнено с возможностью передачи указания как части сообщения протокола конфигурирования.

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

В соответствии с вариантами реализации устройство-Заявитель также выполнено с возможностью передачи указания о том, как повторно конфигурировать устройство-Заявитель. Указание о том, как повторно конфигурировать, содержит по меньшей мере одно из указания необходимости сброса, текстового описания, содержащего инструкции, и URL для документа, описывающего, как повторно конфигурировать. После этого Конфигуратор (или любое другое устройство с пользовательским интерфейсом) может отобразить эту информацию пользователю, чтобы избавить его от необходимости искать ее. Указание может содержать информацию о том, перезаписывает ли повторное конфигурирование предыдущую конфигурацию или добавляет к предыдущей конфигурации.

Информация о повторном конфигурировании Заявителя может быть отображена Конфигуратором или устройством, соединенным с Конфигуратором, чтобы сэкономить пользователю время на поиск этой информации. Кроме того, указание о том, добавляет ли повторное конфигурирование к существующей конфигурации или перезаписывает ее, позволяет надлежащим образом запрограммированному Конфигуратору решить, прерывать или нет повторное конфигурирование на устройстве, которое было правильно сконфигурировано.

В соответствии с еще одним аспектом предложено "устройство-Конфигуратор" (Configurator device), выполненное с возможностью конфигурирования устройства для связи в беспроводной сети и сконфигурированное для участия в протоколе конфигурирования с устройством-Заявителем и в рамках протокола конфигурирования обнаружения в сообщении от устройства-Заявителя указания относительно предыдущей попытки конфигурировать устройство-Заявитель.

В соответствии с вариантом реализации устройство-Конфигуратор также выполнено с возможностью прерывания протокола конфигурирования, если указание указывает на успешное конфигурирование. Это может быть полезно, когда пользователь хочет выполнить повторное конфигурирование только из-за проблемы. Пользователь мог подумать, что возникла проблема с соединением, но может обнаружить, что проблемы с конфигурацией нет, и поэтому нет необходимости переделывать или изменять ее.

В соответствии с вариантом реализации устройство-Конфигуратор определяет из сообщения, что имела место предыдущая попытка конфигурировать устройство-Заявитель, чтобы отобразить в пользовательском интерфейсе соответствующую информацию, указывающую, что имело место предыдущая попытка конфигурировать устройство-Заявитель. Устройство-Конфигуратор, способное обнаруживать указание, может затем информировать пользователя о содержимом и реагировать в соответствии с этим содержимым путем изменения последовательности операций процесса конфигурирования.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Вышеприведенные, как и дополнительные, задачи, признаки и преимущества раскрытых устройств, систем и способов будут лучше понятны из последующего иллюстративного и не имеющего ограничительного характера описания вариантов реализации устройств и способов со ссылкой на прилагаемые чертежи, на которых:

на Фиг. 1 представлена беспроводная сеть, для которой желательно конфигурировать устройства, чтобы добавить их;

на Фиг. 2 представлена последовательность операций процесса конфигурирования в соответствии с вариантом реализации,

на Фиг. 3a представлен пример кадра MAC 802.11, который может соответствовать варианту реализации;

на Фиг. 3b представлен атрибут в соответствии с вариантом реализации для кадра MAC 802.11.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

В последующем описании одинаковые ссылки обозначают аналогичные элементы.

На Фиг. 2 представлена последовательность операций управляемого устройством способа конфигурирования в соответствии с вариантами реализации, при этом одно устройство, такое как третье устройство 9, изображенное на Фиг. 1, может быть сконфигурировано и соединено с другим устройством, таким как сложное или простое устройства 4, 5, изображенные на Фиг. 1. Третье устройство 9 и устройства 4, 5 соответствуют вариантам реализации. В качестве примера будет рассмотрен случай с простым устройством 5. Следует понимать, что хотя в большей части данного описания приведены примеры, включающие сеть с устройством, таким как AP 2, процесс может работать в ситуации с одноранговыми устройствами.

Одним из примеров управляемого устройством способа конфигурирования является протокол предоставления устройств (Device Provisioning Protocol, DPP), который применяют в сетях, использующих Wi-Fi или IEEE 802.11. В протоколе предоставления устройств (DPP) устройство, действующее как конфигуратор DPP, может безопасно конфигурировать любое Wi-Fi-совместимое устройство для соединения с точкой доступа Wi-Fi.

На этапе S1 процесс начинается, когда два устройства 9 и 5 не соединены, а устройство 5 не сконфигурировано. В целях обсуждения устройство 9 будет использовано для конфигурирования устройства 5 для присоединения к беспроводной сети 1, поэтому устройство 9 может называться Конфигуратором, а устройство 5 - Заявителем (поскольку оно «регистрируется» в беспроводной сети 1).

На этапе S2, часто называемом «начальной загрузкой», одно устройство получает открытый ключ (B_R) начальной загрузки другого устройства для подлежащего конфигурированию устройства. Это происходит с помощью других средств, нежели в технологии беспроводной связи, и поэтому обычно называется «внеполосной» (out-of-band, OOB) связью. Примерами этого могут быть считывание пользователем QR-кода на "Ответчике" (Responder) с помощью некого устройства, связь ближнего действия (Near Field Communication, NFC) между двумя устройствами или с устройством другой беспроводной технологии, например Bluetooth. Процесс начальной загрузки инициируется вмешательством пользователя. Если начальная загрузка была успешной, процесс переходит к этапу S3, и устройства 10, 5 «первоначально загружены», в противном случае они возвращаются в состояние «начало» на этапе S1. В любом случае устройство-Заявитель (в данном случае простое устройство 5) может записать в соответствующее хранилище, например, в виде указателя в регистре памяти, результат процесса начальной загрузки. Простые устройства часто запрограммированы на пробуждение после изготовления или после сброса и включение своего радио в канале, указанном в их QR-коде, для конфигурирования и начала прослушивания сообщения запроса на проверку подлинности (непростое устройство зачастую будет установлено в этот режим его пользователем, например выполняющим его сброс).

На этапе S4 устройства 9, 5 выполняют процедуру проверки подлинности, при этом устройства устанавливают «доверие», т.е. пользователь может быть уверен в том, что устройства являются теми, которыми они считают себя, а не другими неизвестными (и потенциально вредоносными) устройствами, «выдающими» себя за то или иное устройство, о которых идет речь. Сообщение отправляют от одного устройства, запрашивающего начало проверки подлинности. Это сообщение может быть отправлено либо устройством, выполняющим конфигурирование (Конфигуратор), либо устройством, которое нужно конфигурировать (Заявитель). В данном примере третье устройство 9 действует как Конфигуратор, а простое устройство 5 - как Заявитель. Следует отметить, что третье устройство 9 показано как соединенное с сетью 1, хотя это не обязательно требуется для работы вариантов реализации. Устройство, начинающее беспроводной обмен данными, называют "Инициатором" (Initiator), а отвечающее устройство называют Ответчиком. Протокол DPP, в частности, позволяет как устройству Конфигуратору, так и устройству-Заявителю действовать в качестве Инициатора протокола DPP, при этом указанное другое устройство автоматически становится Ответчиком. Простые устройства или безголовые устройства обычно будут принимать роль Ответчика.

Указанное другое устройство реагирует на это сообщение. Если сообщение запроса на проверку подлинности правильно декодировано и содержит информацию, указывающую, что Инициатором является устройство, за которое его принимает пользователь, и обладает требуемыми возможностями, ответное сообщение указывает, что сообщение было «принято», и содержит информацию, необходимую Инициатору для проверки учетных данных Ответчика, и что он тоже обладает требуемыми возможностями. Если эти два устройства не принимают от указанного другого устройства требуемую информацию, процесс прерывается, и устройство возвращается в состояние начальной загрузки на этапе S3. Если Инициатор является Заявителем, сообщение запроса на проверку подлинности может также содержать дополнительную часть, указывающую результат предыдущей попытки конфигурировать Заявителя. Если Ответчик является Заявителем, то сообщение ответа по проверке подлинности может содержать дополнительную часть, указывающую результат предыдущей попытки. Следует понимать, что указание также указывает, была ли предыдущая попытка или не была.

В случае протокола DPP первое сообщение является сообщением запроса на проверку подлинности, а ответное сообщение является ответом по проверке подлинности DPP. Ответчик проверяет, содержит ли сообщение ответа по проверке подлинности DPP правильно сформированный криптографический хэш открытого ключа начальной загрузки Ответчика, и имеет ли он экземпляр открытого ключа начальной загрузки Инициатора. Ответчик отправляет сообщение ответа по проверке подлинности DPP, указывающее, можно ли продолжить проверку подлинности. Если нет, например, из-за неудачной попытки расшифровать зашифрованное одноразовое случайное число в сообщении запроса на проверку подлинности DPP, процесс прерывается. Ответ по проверке подлинности DPP содержит криптографический хэш открытого ключа начальной загрузки Ответчика и может содержать хэш открытого ключа начальной загрузки Инициатора. Заявитель может получить этот открытый ключ посредством внеполосной связи, что не меняет сути дела для Инициатора. После этого открытый ключ начальной загрузки Инициатора может быть использован для взаимной проверки подлинности. Без открытого ключа начальной загрузки Инициатора только Инициатор может проверить подлинность Заявителя, но никак иначе.

В случае DPP указание результата предыдущей попытки может быть в форме специально предназначенного дополнительного атрибута в теле кадра сообщения запроса на проверку подлинности или ответа по проверке подлинности DPP. Форматы и содержимое сообщений рассматриваются со ссылкой на Фиг. 3.

Если сообщение ответа по проверке подлинности указывает, что Ответчик принял сообщение запроса на проверку подлинности, и ответ удовлетворяет критериям, накладываемым настройкой Инициатора, Инициатор выдает сообщение подтверждения проверки подлинности. Если значения проверки подлинности в сообщениях ответа по проверке подлинности и подтверждения проверки подлинности признаны соответствующими устройствами правильными, эта часть протокола, часть проверки подлинности, прошла успешно, процесс достиг этапа S6, и можно начинать конфигурирование. Сообщение подтверждения может также содержать указание результата предыдущей попытки конфигурирования, в которой Заявитель является также Инициатором.

В случае протокола DPP сообщение подтверждения проверки подлинности является сообщением подтверждения проверки подлинности DPP.

На этапе S7 устройство-Заявитель отправляет сообщение запроса на конфигурирование с информацией о том, какого типа конфигурация требуется Заявителю. Если Конфигуратор в состоянии удовлетворить запрос, он отправляет сообщение с необходимой Заявителю информацией, такой как сетевой ключ. После этого процесс завершается на этапе S8 успешным конфигурированием Заявителя. В соответствии с вариантом реализации запрос на конфигурирование может содержать указание результата предыдущей попытки конфигурирования.

В случае DPP сообщение запроса является запросом на конфигурацию DPP, а ответ Конфигураторов является сообщением ответа на конфигурирование DPP. Ответ на конфигурирование DPP может содержать идентификатор набора служб (service set identifier, SSID) сети, с которой должен соединиться Заявитель, и может содержать DPP-коннектор. DPP-коннектор может рассматриваться как сертификат, имеющий цифровую подпись Конфигуратора, и содержит, среди прочего, открытый ключ доступа к сети Заявителя. Сообщение ответа по конфигурированию DPP может также содержать открытый ключ подписи Конфигуратора. Благодаря чему другие устройства, которые были сконфигурированы тем же самым Конфигуратором, могут проверить, могут ли они доверять открытому ключу доступа к сети других устройств. Сообщение ответа по конфигурированию DPP может также содержать парольную фразу или предварительный общий ключ (Pre Shared Key, PSK) сети. Заявитель отправляет сообщение результата конфигурирования DPP (в зависимости от версии DPP) Конфигуратору, чтобы дать тому знать, принимает ли он конфигурирование или нет. Неполучение этого сообщения Конфигуратором может указывать Конфигуратору на наличие проблемы с Wi-Fi между Конфигуратором и Заявителем. Затем «предположительно сконфигурированный» Заявитель может отправить свой коннектор на AP 2, сконфигурированную с помощью DPP. Если подпись коннекторов признана правильной, и если AP 2 имеет соответствующий коннектор, т.е. коннектор для той же самой сети, подписанный тем же самым Конфигуратором, AP2 отправляет свой собственный коннектор Заявителю. Заявитель и AP 2 могут вычислить симметричный ключ на основе ключа доступа к сети друг друга, указанных в коннекторах, и своего закрытого ключа доступа к сети методом Диффи-Хеллмана.

Если Заявитель принял пароль Wi-Fi или предварительный общий ключ (PSK), Заявитель пытается связаться с AP 2 обычным образом посредством 4-этапного квитирования, как определено в [802.11].

С другой стороны, если Заявителю (простое устройство 5 в данном примере) не удается соединиться, он прекращает попытки по истечении периода времени ожидания, на который он запрограммирован, сохраняет информацию о попытке конфигурирования и неудаче соединения и останавливается. Время ожидания может быть очень большим или бесконечным. Пользователь, когда он понимает, что присоединение к сети 1 или соединение к ней не сработало, может попытаться понять ситуацию и повторить попытку конфигурирования, а затем заставить простое устройство 5 повторно попытаться присоединиться к сети 1.

В случае, если Конфигуратор обнаруживает, что Заявитель подвергся предыдущей попытке конфигурирования, существуют ряд возможностей, которые зависят, в частности, от того, с какими возможностями выполнен заявитель, и каким был предыдущий результат.

Многие устройства, такие как простое устройство 5, выполнены с возможностью хранения только одной конфигурации одновременно. Кроме того, многие устройства изготовлены без конфигурации, но запрограммированы на отклонение или игнорирование дальнейших попыток конфигурировать их после того, как они уже были сконфигурированы - имеют «блокировки конфигурирования», например, указатель, к которому обращаются всякий раз, когда происходит попытка конфигурирования. Это поведение можно сравнить с процессом импринтинга у некоторых животных, когда молодое животное учится признавать одну другую особь своей «матерью», если видит ее в определенное время. После запечатления в памяти молодое животное отказывается считать матерью любую другую особь. Чтобы повторно конфигурировать устройство требуется некоторого рода сброс, чтобы снять указатель, который препятствует участию устройства в процессе конфигурирования. Такой указатель может быть просто указателем состояния со значениями, указывающими либо «сконфигурировано», либо «не сконфигурировано».

В случае, если предыдущее конфигурирование было успешным и выполнено для рассматриваемой сети, существуют различные возможности в зависимости от того, как на какое поведение запрограммирован заявитель после того, как он был сконфигурирован. Если простое устройство 5 запрограммировано не принимать новые конфигурации без сброса, то процесс конфигурирования будет прерван, поскольку Заявитель не будет отправлять ответы, требуемые для продолжения процесса.

Конфигуратор тоже может вести себя по-разному. В одном варианте реализации Конфигуратор может быть выполнен с возможностью прерывания конфигурирования и перехода непосредственно к этапу S8 на том основании, что нет смысла повторно выполнять процедуру (и подвергаться риску, что она не удастся). Ветвление последовательности операций может произойти, как только Конфигуратор определил, что Заявитель уже был успешно сконфигурирован, например, если соответствующее указание было обнаружено в одном из сообщений проверки подлинности. Когда Конфигуратор имеет пользовательский интерфейс, он может информировать пользователя, что для сети, о которой идет речь, имело место предыдущее успешное конфигурирование. В альтернативном варианте реализации Конфигуратор может просто продолжить процесс и, если Заявитель находится в режиме принятия конфигурирования, просто добавляет новую конфигурацию в хранилище конфигураций Заявителя или перезаписывает предыдущую конфигурацию, причем Заявитель имеет только одно хранилище конфигураций, что зачастую характерно для простых устройств. Когда Заявитель также предоставляет информацию о том, как конфигурировать его (как описано ниже), Конфигуратор может узнать, как повлияет повторное конфигурирование на старую конфигурацию (например, перезапись), и информирует пользователя посредством своего собственного или удаленного пользовательского интерфейса на другом устройстве, таком как AP 2, соединенном с Конфигуратором. Конфигуратор может быть также запрограммирован на продолжение конфигурирования для устройств, которые добавляют новую конфигурацию в свои хранилища конфигураций, но прекращать конфигурирование для простых устройств, которые могут только перезаписывать существующую конфигурацию.

С другой стороны, если простое устройство 5 было успешно сконфигурировано, но для другой сети, то его нужно будет повторно конфигурировать, и тогда ситуация становится такой же, как если бы предыдущее конфигурирование не удалось.

Когда требуется повторное конфигурирование, если предыдущая попытка не удалась или была не для той сети, процесс переходит к этапу S9, на котором Конфигуратор может посредством своего собственного ПИ или посредством удаленного ПИ информировать пользователя о результате предыдущей попытки. Помимо информирования пользователя о том, что нужно повторить конфигурирование, это может также указывать, требуется ли выполнить сброс рассматриваемого устройства, чтобы добиться его участия в новом конфигурировании. Если требуется, пользователь может выполнить сброс устройства и повторить попытку конфигурирования. Сброс простого устройства 5 помимо удаления любых блокировок конфигурирования изменяет запись предыдущих попыток конфигурирования таким образом, чтобы избежать преждевременного прекращения протокола конфигурирования Конфигуратором. Например, это может включать изменение значения в записи предыдущей попытки так, чтобы соответствующим образом запрограммированный Конфигуратор мог обнаружить это значение и продолжить конфигурирование. В альтернативном варианте реализации Конфигуратор может быть запрограммирован всегда продолжать конфигурирование, если предыдущий результат указывает на неудачное соединение.

Сброс простого устройства 5 может быть выполнен с помощью кнопки 8. Кнопка 8 может быть кнопкой питания, и в таком случае сброс может быть достигнут коротким нажатием по сравнению с длинным нажатием, необходимым для фактического выключения питания устройства. В альтернативном варианте реализации кнопка 8 моет быть утоплена в отверстии во избежание случайного сброса.

Простое устройство 5 может иметь два уровня сброса - частичный сброс, который стирает любые блокировки конфигурирования, но не удаляет запись предыдущих попыток конфигурирования, и полный или всеобъемлющий сброс для возврата устройства к так называемым заводским настройкам, включая блокировку конфигурирования/указатель состояния. Возможны различные способы реализации двухуровневого сброса, такие как короткое нажатие и длинное нажатие или одно нажатие для одного уровня и два нажатия в течение определенного отрезка времени для другого уровня.

В варианте реализации простое устройство 5, после того, как оно сконфигурировано, осуществляет поиск сети, для которой оно сконфигурировано, и пытается соединиться с ней. Если оно в состоянии соединиться, оно делает это и остается в канале сети, выбранном между ним и сетью. Если нет, время попытки соединиться истекает, и устройство 5 отказывается от дальнейших попыток. После этого простое устройство 5 возвращается к прослушиванию либо канала, используемого по умолчанию, либо канала, который был предоставлен ему в процессе начальной загрузки. Кроме того, оно устанавливает указатель состояния соединения на «сконфигурировано», записывает информацию о неудачной попытке соединения и помещает ее в новый атрибут состояния соединения для своего следующего сообщения запроса на конфигурирование.

В одном варианте реализации простое устройство 5 может иметь протокол, такой как короткое нажатие для частичного сброса и длинное нажатие для полного сброса.

В одном варианте реализации в том случае, когда не было предпринято предыдущих попыток конфигурирования Заявителя, указание может быть опущено. Когда Конфигуратор замечает отсутствие указания, он просто продолжает протокол. В другом варианте реализации указание присутствует и содержит значение которое указывает, что предыдущих попыток конфигурирования не было предпринято. Опять же, заметив эту ситуацию, Конфигуратор просто продолжает.

Общая последовательность операций попытки добавить простое устройство в сеть можно рассматривать с точки зрения пользователя в следующем примере, в котором используют протокол DPP.

Простое устройство 5 пробуждается после изготовления или после сброса до заводских настроек и включает свое радио, устанавливает его на канал, указанный в QR-коде для конфигурации DPP и начинает прослушивание на предмет сообщения запроса на проверку подлинности DPP. Непростое устройство будет установлено в этот режим его пользователем.

Простое устройство 5 получает конфигурацию посредством протокола DPP и принимает конфигурацию в сообщении ответа по конфигурированию DPP от конфигуратора.

Простое устройство пытается соединиться с сетью, для которой оно было только что сконфигурировано.

В одном случае простое устройство 5 в состоянии успешно соединиться. Оно устанавливает свою блокировку конфигурирования и больше не реагирует на конфигурирование DPP до тех пор, пока не будет возвращено в состояние сброса до заводских настроек. На этом последовательность операций заканчивается.

В другом случае простое устройство 5 не в состоянии соединиться. Спустя какое-то время оно прекращает попытки соединиться, сохраняет причину неудачи в памяти в качестве предыдущего результата конфигурирования и снова начинает реагировать на конфигурирование DPP либо после простого (не до заводских настроек) сброса, либо сразу после прекращения попыток соединиться с сетью. Когда его снова конфигурируют, оно включает причину неудачи соединения в одно из четырех возможных сообщений протокола DPP. Причина неудачи может быть стерта из памяти во время сброса до заводских настроек.

Во время попытки создания новой конфигурации т.е. когда устройство является «новым» в том смысле, что не известно, было ли это устройство когда-либо сконфигурировано или соединено с сетью 1, могут возникнуть следующие ситуации.

Либо предыдущий результат конфигурирования отсутствует (например, после того, как простое устройство 5 подвергли сбросу до заводских настроек). Конфигуратор просто отправляет ответ по конфигурированию DPP, чтобы сконфигурировать Заявителя, как предписывает немодифицированный протокол DPP.

Либо предыдущий результат конфигурирования доступен. При этом существуют две возможности.

Во-первых, предыдущий результат конфигурирования является успешным; конфигуратор просто отправляет ответ по конфигурированию DPP Заявителю. Простое устройство «забудет» предыдущую конфигурацию и будет (пытаться) использовать исключительно новую конфигурацию. Непростое устройство и, в частности, мобильное устройство, такое как переносной компьютер или смартфон, добавит новую конфигурацию в свой список конфигураций, поэтому оно остается в состоянии соединяться с ранее сконфигурированными сетями при перемещении с места на место. Заявитель мог включить информацию, указывающую, будет ли он пополнять свое существующее хранилище конфигураций или перезаписывать его.

Во-вторых, предыдущий результат конфигурации может быть неудачным; Конфигуратор может показать это пользователю. Пользователь может попытаться улучшить данную ситуацию на основе следующего. Пользователь может, например, решить сконфигурировать устройство для другой сети, точки доступа которой ближе к Заявителю, или пользователь может просто попытаться выполнить то же самое конфигурирование еще раз. В конечном итоге отправляют сообщение ответа по конфигурированию DPP, содержащее код состояния DPP, установленный на STATUS_OK (СОСТОЯНИЕ_В_ПОРЯДКЕ), и объект конфигурирования DPP. С практической точки зрения пользователь может также попытаться и исправить ситуацию, например, путем перемещения Заявителя ближе к точке доступа, или, наоборот, установив канал Wi-Fi точки доступа на канал, который поддерживается Заявителем, и т.д. Предпринимая такие действия, пользователь прервет конфигурирование DPP, и будет отправлено сообщение ответа по конфигурированию DPP с кодом состояния DPP, установленным на STATUS_CONFIG_REJECTED (СОСТОЯНИЕ_КОНФИГ_ОТКЛОНЕНО). Заявитель либо снова начнет реагировать на конфигурирование DPP после простого сброса, либо продолжит реагировать на конфигурирование DPP (в зависимости от того, как он запрограммирован). Обычно сообщение ответа по конфигурированию DPP отправляют спустя доли секунды после приема запроса на конфигурирование DPP, а время ожидания Заявителем сообщения ответа по конфигурированию DPP может быть порядка секунды. По истечении времени ожидания Заявитель может решить отправить свой запрос на конфигурирование DPP еще раз, поскольку Конфигуратор DPP мог не принять предыдущий запрос (например, из-за помех). В обоих случаях, когда предыдущий результат конфигурирования был неудачным (конфигурирование заново или отклоненное конфигурирование), сообщение ответа по конфигурированию DPP не будет отправлено вскоре после приема запроса на конфигурирование DPP, чтобы пользователь мог оценить ситуацию и решить, как действовать. Это могут быть десятки секунд. Соответственно, Заявитель должен установить время ожидания для ожидания сообщения ответа по конфигурированию DPP на гораздо большее значение, возможно, где-нибудь даже порядка минуты или больше.

Альтернативным решением может быть продление фазы конфигурирования (DPP) за счет отправки еще раз сообщения результата конфигурирования после того, как Заявитель успешно соединился с AP 2. Проблема с этим заключается в том, что Заявителю может потребоваться много времени для поиска AP 2 в множестве каналов, причем в течение этого времени Конфигуратор должен оставаться в канале конфигурирования и прослушивать Заявителя - процесс может завершиться по истечении времени ожидания. Если Заявитель действительно соединился с AP 2, тогда Заявитель должен, опять же, покинуть канал AP, чтобы отправить сообщение результата конфигурирования DPP, что неэффективно и увеличивает риск неудачи процесса в целом после этого.

Как объяснено в других разделах настоящего документа, безголовое устройство, такое как простое устройство 5, часто реализуют таким образом, что оно входит в режим конфигурирования или начинает реагировать на конфигурирование (DPP) после сброса до заводских настроек. Как упоминалось ранее, у устройства могут быть проблемы с доступом к сети после того, как его конфигурировали. Безголовое устройство может прекратить дальнейшие попытки соединения с сетью, для которой оно сконфигурировано, спустя некоторое время и, например, вернуться в состояние простого сброса (в котором оно по-прежнему имеет конфигурацию, а проблемы с доступом к сети доступны для сообщения конфигуратору) или может снова войти в режим, в котором оно реагирует на конфигурирование (DPP). Если пользователь хочет сконфигурировать устройство еще раз, пользователь должен сбросить устройство в случае устройства в соответствии с первым примером, но не в тому случае, если устройство относится к типу устройств, которые автоматически возвращаются в состояние готовности к конфигурированию. Чтобы помочь пользователю в том, как повторно конфигурировать устройство, устройство может включать еще один атрибут в любое из сообщений, отправляемых конфигуратору, в которое оно может также включить атрибут PrevCon, в котором устройство может предоставить информацию о том, как повторно конфигурировать его. Этот атрибут может называться атрибутом ReconfigureInfo. Это может быть что угодно, от простого 1-битового значения да/нет, требуемого для повторного конфигурирования, до текстового описания того, как повторно конфигурировать его, или URL, указывающего на документ, который описывает, как повторно конфигурировать устройство. Этот атрибут может указывать, как долго устройство будет пытаться соединиться с сетью, прежде чем снова станет реагировать на повторное конфигурирование. Это особенно полезно для безголовых устройств. Устройства должны включать этот атрибут ReconfigureInfo уже в любое из сообщений, отправляемых конфигуратору во время первой попытки конфигурирования, чтобы эта информация была доступна для показа конфигуратором пользователю, когда пользователь подозревает, что у только что сконфигурированного устройства проблемы доступа к сети. Это может быть в виде кнопки с надписью «Нажмите в месте X в случае проблем с соединением». Атрибут ReconfigureInfo может также содержать указание, будет ли новая конфигурация перезаписывать существующую, или будет добавлена к ней.

Преимуществом предложенных вариантов реализации является то, что пользователь может быть информирован о причине, по которой устройство, в частности, простое или безголовое устройство, не присоединится к сети или не свяжется с требуемой сетью. Кроме того, пользователь может быть поставлен в известность о проблеме без необходимости в проверке пользовательского интерфейса AP 2. Поскольку обнаружение проблемы основано на определении наличия предыдущей попытки, и это определение выполняют во время исполнения процедуры конфигурирования, а не после этой процедуры, необходимость прерывания связи для проверки успешности конфигурирования исключается. Кроме того, пользователь может быть информирован о действиях, которые могут потребоваться для исправления ситуации.

На Фиг. 3 представлен пример кадра управления доступом к среде (Medium Access Control, MAC). Рассматриваемый пример относится к стандарту IEEE 802.11. Однако следует понимать, что возможны другие форматы, если только имеется тело или содержащая полезную нагрузку часть кадра. В целях настоящего изобретения другие части, заголовок кадра и проверка ошибок (в данном документе FCS), не важны.

На фазе протокола конфигурирования DPP процедуры DPP общий формат кадра MAC является форматом кадра общей службы извещения (Generic Advertisement Service, GAS) в соответствии со стандартом IEEE 802.11. На фазе протокола проверки подлинности DPP процедуры DPP общий формат кадра MAC является форматом кадра Public Action в соответствии со стандартом IEEE 802.11. Атрибуты могут быть добавлены в сообщения запроса на проверку подлинности, ответа по конфигурированию, подтверждения конфигурирования и запроса на конфигурирование. В настоящем документы эти новые атрибуты для удобства именуются «PrevCon» и «ReconfigurationInfo», хотя могут быть использованы другие названия. Между собой они содержат информацию о предыдущей попытке конфигурирования, что необходимо для повторного конфигурирования и указания того, перезаписывать ли повторной конфигурацией или дополнять ею. В одном варианте реализации они структурированы в виде отдельных атрибутов, а в другом варианте реализации эта информация представлена в структуре с одним атрибутом.

Формат информационной части сообщения запроса на проверку подлинности DPP для устройства-Заявителя в соответствии с одним вариантом реализации следующий:

SHA256(BR), SHA256(BI), PI, [Канал,] {I-nonce, I-capabilities, PrevCon}k1

где

B_R - открытый ключ начальной загрузки Ответчиков;

B_I - открытый ключ начальной загрузки Инициаторов;

PI - ключ протокола инициатора;

[канал] - необязательное указание канала, предпочитаемого Инициатором;

I-nonce - одноразовое случайное число Инициатора;

I-capabilities - возможности Инициатора;

PrevCon - результат предыдущей попытки;

{}k1 означает, что информация внутри фигурных скобок была зашифрована в режиме AES-SIV (RFC5297) с использованием ключа k1. В дополнение к шифрованию, а, значит к защите конфиденциальности информации, AES-SIV обеспечивает защиту целостности шифруемой информации. Кроме того, процесс шифрования AES-SIV может защитить целостность дополнительных данных, передаваемых открытым текстом (аутентифицированные связанные данные - uthenticated Associated Data, AAD). Во время расшифрования AES-SIV изменение любого бита в AAD и зашифрованной информации будет обнаружено, и расшифрование зашифрованных данных будет объявлено недействительным. В DPP атрибут, предшествующие атрибутам в фигурных скобках, являются частью аутентифицированных связанных данных.

Еще в одном варианте реализации формат следующий:

SHA256(BR), SHA256(BI), PI, PrevCon, [Канал,] {I-nonce, I-capabilities}k1

В этом варианте реализации атрибут, касающийся предыдущей попытки конфигурирования (PrevCon), отправляют открытым текстом, т.е. незашифрованным. Атрибут PrevCon должен быть частью аутентифицированных связанных данных (AAD), используемых для шифрования AES-SIV {I-nonce, I-capabilities}k1, чтобы защитить целостность атрибута PrevCon.

Еще в одном варианте реализации зашифрованная часть, (представленная между скобками {}) или незашифрованная часть может также содержать атрибут ReconfigurationInfo.

В части проверки подлинности DPP протокола конфигурирования, и когда устройство Ответчик является Заявителем, формат ответа по проверке подлинности DPP в соответствии с вариантом реализации следующий:

DPP Status, SHA256(B _R ), SHA256(B _I ), {R-nonce, I-nonce, R-capabilities, PrevCon, {R-auth} _ke } _k1

где PrevCon - атрибут, касающийся предыдущей попытки конфигурирования, как и прежде.

DPP Status, SHA256(B _R ), SHA256(B _I ), PrevCon, {R-nonce, I-nonce, R-capabilities, { R-auth } _ke } _k1

В этом варианте реализации атрибут, касающийся предыдущей попытки конфигурирования (PrevCon), отправляют открытым текстом, т.е. незашифрованным. Атрибут PrevCon должен быть частью аутентифицированных связанных данных (AAD), используемых для шифрования AES-SIV {R-nonce, I-nonce, R-capabilities, { R-auth } _ke } _k1, чтобы защитить целостность атрибута PrevCon.

В части проверки подлинности DPP протокола конфигурирования, и когда устройство Ответчик является Конфигуратором, формат подтверждения проверки подлинности DPP в соответствии с вариантом реализации следующий:

DPP Status, SHA256(B _R ), SHA256(B _I ), {PrevCon, I-auth } _ke

DPP Status, SHA256(B _R ), SHA256(B _I ), PrevCon, {I-auth } _ke

В этом варианте реализации атрибут, касающийся предыдущей попытки конфигурирования (PrevCon), отправляют открытым текстом, т. е. незашифрованным. Атрибут PrevCon должен быть частью аутентифицированных связанных данных (AAD), используемых для шифрования AES-SIV {I-auth } _ke, чтобы защитить целостность атрибута PrevCon.

Формат запроса на конфигурирование DPP в соответствии с вариантом реализации следующий:

{E-nonce, configAttrib, PrevCon} _ke

где E-nonce - одноразовое случайное число Заявителя, а configAttrib - атрибут конфигурирования DPP, как определено в спецификации DPP.

PrevCon, {E-nonce, configAttrib} _ke

В этом варианте реализации атрибут, касающийся предыдущей попытки конфигурирования (PrevCon), отправляют открытым текстом, т.е. незашифрованным. Атрибут PrevCon должен быть частью аутентифицированных связанных данных (AAD), используемых для шифрования AES-SIV {E-nonce, configAttrib} _ke, чтобы защитить целостность атрибута PrevCon.

Формат ответа по конфигурированию DPP следующий:

DPP Status, {E-nonce, configurationObject } _ke

На Фиг. 3b показан общий формат атрибута 31 PrevCon. Идентификатор атрибута идентифицирует атрибут как являющийся записью предыдущей попытки конфигурирования. Длина описывает длину следующей части, переменной. Переменная может содержать некоторую или всю из следующей информации:

- результат, т.е. успех или неудача, причем успех может означать, что Заявитель мог связываться точкой доступа, которая использует SSID, сконфигурированный в Заявителе, и мог успешно связываться с этой точкой доступа с помощью DPP-коннектора, парольной фразы Wi-Fi или Wi-Fi PSK, который Заявитель принял во время конфигурирования, так что он получил доступ по сети к сконфигурированному SSID,

- причина неудачи,

- SSID сети, в которой была предпринята предыдущая попытка,

- мощность передачи, используемая при попытке соединиться с сетью,

- список каналов Wi-Fi, найденных для сети,

- список SSID, которые были найдены при сканировании каналов Wi-Fi, но не являются теми SSID, к которым нужно подсоединиться.

«Причиной неудачи» может быть:

- Заявитель мог связаться с точкой доступа, которая использует SSID, сконфигурированный в Заявителе, и отправить свой DPP-коннектор этой точке доступа в сообщении запроса на обнаружение одноранговых узлов DPP, однако сообщение ответа на обнаружение одноранговых узлов DPP, принятое от точки доступа, вернуло состояние DPP «STATUS_INVALID_CONNECTOR» (СОСТОЯНИЕ_НЕВЕРНЫЙ_КОННЕКТОР) или «STATUS_NO_MATCH» (СОСТОЯНИЕ_НЕ_СООТВЕТСТВУЕТ). Причины для этих кодов ошибки перечислены в пункте 6.4.1 [DPP],

- Заявитель мог связаться с точкой доступа, которая использует SSID, сконфигурированный в Заявителе, но предоставленные парольная фраза Wi-Fi или Wi-Fi PSK (предварительный общий ключ), сконфигурированные в Заявителе, оказались неверными при попытке связаться с точкой доступа,

- Заявитель отсканировал список каналов (список прилагается), но не смог найти точку доступа со сконфигурированным SSID,

- конфигурировать не удалось.

Общий формат атрибута ReconfigurationInfo имеет ту же самую общую структуру.

Поскольку Конфигуратор должен обнаружить это, он должен быть запрограммирован соответствующим образом для правильного синтаксического разбора сообщений. Следует понимать, что это увеличивает сложность и удлиняет время исполнения для Конфигуратора. Это также увеличивает сложность на стороне Заявителя ввиду необходимости более сложного встроенного программного обеспечения и энергонезависимой памяти большего объема. Следует иметь в виду, что существует сильное давление в отношении снижения стоимости таких устройств, и даже кажущиеся небольшими ее увеличения требуют обоснования. Кроме того, многие такие устройства питаются от батареи и любые дополнительные энергозатраты, например, на извлечение информации, составление более сложных сообщений и отправку этих более сложных и длинных сообщений, встречают активное противодействие, особенно когда батареи маленькие и рассчитаны на длительный срок службы.

Аспекты вариантов реализации могут быть реализованы в компьютерном программном продукте, который может быть хранящимся на компьютерочитаемом запоминающем устройстве набором компьютерных программных инструкций, которые могут быть исполнены компьютером. Инструкции могут быть в любом механизме интерпретируемого или исполняемого кода, включая без ограничений сценарии, интерпретируемые программы, библиотеки динамической компоновки (DLL) или классы Java. Инструкции могут быть предусмотрены в виде полностью исполнимых программ, частично исполнимых программ, в виде модификаций к существующим программам (например, обновления) или расширений для существующих программ (например, подключаемые модули). Кроме того, части обработки в соответствии с настоящим изобретением могут быть распределены по нескольким компьютерам или процессорам.

В число носителей данных, пригодных для хранения компьютерных программных инструкций, входят все виды энергонезависимой памяти, в том числе без ограничений СППЗУ, ЭСППЗУ и устройства флэш-памяти, магнитные диски, такие как внутренние или внешние накопители на жестких дисках, съемные диски и диски CD-ROM. Компьютерный программный продукт может быть распределенным на таких носителях данных, или может предлагаться для загрузки посредством HTTP, FTP, электронной почты или через сервер, соединений с сетью, такой как Интернет.

Следующие документы могут быть использованы в качестве справочных:

[802.11] IEEE Computer Society, «IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications», (IEEE Std. 802.11-2016), December 2016)

[DH] Diffie, W.; Hellman, M. (1976), «New directions in cryptography», IEEE Transactions on Information Theory, 22 (6): 644-654

[DPP] Device Provisioning Protocol - Technical Specification - Version 1.0, Wi-Fi Alliance, 2018, https://www.wi-fi.org/file-member/device-provisioning-protocol-specification.

[RD] The Resurrecting Duckling: Security Issues for Ad-Hoc Wireless Networks, University of Cambridge Computer Laboratory, https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-duckling.pdf

[RFC5297] Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES), October 2008, (https://datatracker.ietf.org/doc/rfc5297/ )

Claims

1. Способ конфигурирования устройства (5) связи без пользовательского интерфейса, запрашивающего регистрацию в беспроводной сети связи, причем устройство (5) связи без пользовательского интерфейса сконфигурировано для участия в протоколе конфигурирования для обеспечения попытки зарегистрироваться в беспроводной сети связи, включающий:

- выполнение протокола конфигурирования устройством (5) связи без пользовательского интерфейса,

- отправку устройством (5) связи без пользовательского интерфейса конфигурирующему устройству (9) связи, выполненному с возможностью конфигурирования устройства связи, запрашивающего регистрацию в беспроводной сети связи, для присоединения к беспроводной сети, во время исполнения протокола конфигурирования, сообщения, содержащего указание состояния предыдущей попытки конфигурирования и указание причины, если предыдущая попытка конфигурирования не удалась, и

- выполнение конфигурирующим устройством (9) связи прерывания конфигурирования, если конфигурирование прошло успешно, или отображения в пользовательском интерфейсе информации о том, что предыдущая попытка не удалась.

2. Способ по п. 1, в котором сообщение является одним из сообщения запроса на проверку подлинности, сообщения ответа по проверке подлинности, сообщения подтверждения проверки подлинности или сообщения запроса на конфигурацию.

3. Способ по любому предыдущему пункту, в котором конфигурирование является частью установления связи между устройством (5) связи без пользовательского интерфейса и другим устройством в беспроводной сети связи.

4. Способ по любому предыдущему пункту, в котором указание содержит информацию по меньшей мере об одном из результата предыдущей попытки конфигурирования, выполненного в рамках предыдущей попытки конфигурировании действия, идентификатора сети и указания того, возможно ли повторное выполнение конфигурирования, для которого была предпринята предыдущая попытка конфигурирования, без выполнения сброса.

5. Способ по любому предыдущему пункту, в котором прием сообщения, содержащего указание на успешную предыдущую попытку конфигурирования, приводит к прекращению протокола конфигурирования.

6. Способ по любому предыдущему пункту, в котором прием сообщения, содержащего указание на предыдущую попытку конфигурирования, приводит к отображению принимающим устройством соответствующей информации в пользовательском интерфейсе.

7. Способ по п. 1, в котором указание содержится в сегменте сообщения, который не зашифрован.

8. Способ по п. 1, в котором указание содержится в сегменте сообщения, который зашифрован.

9. Устройство (5) связи без пользовательского интерфейса, выполненное с возможностью связи в беспроводной сети связи, содержащее хранилище и сконфигурированное для участия в протоколе конфигурирования, причем протокол конфигурирования выполнен с возможностью конфигурирования устройства (5) связи без пользовательского интерфейса для обеспечения попытки зарегистрироваться в беспроводной сети связи, причем устройство (5) связи без пользовательского интерфейса выполнено с возможностью сохранения указания причины неудачи соединения с беспроводной сетью связи, если предыдущая попытка конфигурирования не удалась, и передачи конфигурирующему устройству (9) связи, выполненному с возможностью конфигурирования устройства связи, запрашивающего регистрацию в беспроводной сети связи, для присоединения к беспроводной сети, этого указания как части сообщения протокола конфигурирования,

причем конфигурирующее устройство (9) связи выполнено с возможностью прерывания конфигурирования, если конфигурирование прошло успешно, или отображения в пользовательском интерфейсе информации о том, что предыдущая попытка не удалась.

10. Устройство (5) связи по п. 9, также выполненное с возможностью передачи указания о том, как повторно конфигурировать устройство (5) связи без пользовательского интерфейса.

11. Устройство (5) связи по п. 9 или 10, также выполненное с возможностью передачи указания о том, перезаписывает ли повторное конфигурирование предыдущую конфигурацию или добавляет к предыдущей конфигурации.

12. Устройство (5) связи по п. 10 или 11, в котором указание о том, как повторно конфигурировать, содержит по меньшей мере одно из указания необходимости сброса, текстового описания, содержащего инструкции, и URL документа, описывающего, как повторно конфигурировать.

13. Устройство (5) связи по любому из пп. 9–12, также выполненное с возможностью стирания из хранилища указания только после приема полного сброса.

14. Конфигурирующее устройство (9) связи, выполненное с возможностью конфигурирования устройства связи, запрашивающего регистрацию в беспроводной сети связи, для присоединения к беспроводной сети, сконфигурированное для участия в протоколе конфигурирования с устройством (5) связи без пользовательского интерфейса, запрашивающим регистрацию в беспроводной сети связи, и, в рамках протокола конфигурирования, обнаружения в сообщении от устройства (5) связи без пользовательского интерфейса указания относительно предыдущей попытки конфигурировать устройство (5) связи без пользовательского интерфейса,

причем конфигурирующее устройство (9) связи выполнено с возможностью прерывания конфигурирования, если конфигурирование прошло успешно, или отображения в пользовательском интерфейсе информации о том, что предыдущая попытка не удалась,

причем функции, предписанные конфигурирующему устройству (9) связи, реализованы компьютером, исполняющим набор компьютерных программных инструкций, хранящихся на компьютерочитаемом запоминающем устройстве.

15. Конфигурирующее устройство (9) связи по п. 14, также выполненное с возможностью, если конфигурирующее устройство (9) связи определяет из сообщения, что имела место предыдущая попытка конфигурировать устройство (5) связи без пользовательского интерфейса, отображения в пользовательском интерфейсе соответствующей информации, указывающей, что имела место предыдущая попытка конфигурировать устройство (5) связи без пользовательского интерфейса.