Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.LINUX
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.LINUX с датами от 24 Jan 02 06:01:34 до 11 Mar 24 23:35:09, всего сообщений: 8277
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 7416 из 8277 ========================================= RU.LINUX =
От   : Eugene Grosbein                  2:5006/1           17 May 21 04:18:11
Кому : Eugene Muzychenko                                   17 May 21 04:18:11
Тема : Re: hostapd и wpa_supplicatnt в OpenWRT
FGHI : area://RU.LINUX?msgid=grosbein.net+a628a87e
На   : area://RU.LINUX?msgid=2:5000/14+60a11f2c
= Кодировка сообщения определена как: IBM866 =================================
Ответ: area://RU.LINUX?msgid=2:5000/14+60a2613a
==============================================================================
16 мая 2021, воскресенье, в 15:28 NOVT, Eugene Muzychenko написал(а):

EG>> очень сильно сомневаюсь, что это поддерживаемая официально
EG>> конфигурация - одновременно работать точкой доступа и клиентом другой
EG>> точки доступа на одном чипе.
EM> Я тоже сомневался, пока вдруг не обнаружил, что оно работает, причем стабильно
EM> и отлично. Hо после перезагрузки повторить не удалось - hostapd стабильно
EM> ругается, что не может установить параметры драйверу. Больше всего это похоже на
EM> гонки, когда оба демона хотят драйвер, но не синхронизируют свой доступ к нему.

Это не называется "работает стабильно и отлично" :-)

EG>> Возможно, что теоретически это как-то и можно совмещать на одной
EG>> частоте, даже если игнорировать вопрос коллизий, но это пришлось
EG>> бы кодить очень аккуратно с учётом "разделения" чипа между процессами.
EM> Судя по тому, что оно стабильно работало несколько часов под нагрузкой,
EM> проблема с разделением возникает только на этапе инициализации.

Hесколько часов это ни о чём. Мне приходилось дебажить проблему
подобного рода: библиотека неатомарно увеличивает внутренний
счетчик уникальных положительных целых id и если процесс,
её использующий a) долгоживущий и b) многотредовый,
то раз в несколько месяцев (в зависимости от интенсивности
нагрузки) случалось так, что один тред увеличивал счетчик
до INT_MAX, затем параллельно второй тред опять инкрементировал
знаковое целое, получая -1 и либа возвращала значение -1,
зарезервированное для сигнализации ошибки, а errno оставался 0,
потому как никакой сисколл ошибку не возвращал. Что ломало
логику работы приложения, которое на такую подляну никак не рассчитывало.

Простое использование атомиков убрало проблему, но чтобы она случилась,
требовалось два миллиарда инкрементов и долгое время.
А у тебя "несколько часов" :-)

Eugene
--- slrn/1.0.3 (FreeBSD)
* Origin: RDTC JSC (2:5006/1@fidonet)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.045004 секунды