Перейти к содержанию

vasek00

Участники форума
 Профиль  Обзор контента

  • Постов

    4 895

  • Зарегистрирован

  • Посещение

  • Победитель дней

    80

 Тип контента 

Сообщения, опубликованные vasek00

    Не отвечает WEB

    в 2.15

    Опубликовано · Изменено пользователем vasek00

    23 минуты назад, sergeyk сказал:

    У вас есть возможность снять self-test хотя бы на нормально работающем устройстве? 

    Устройство работает нормально с момента установки. Данная фишка выскочила один раз после утреннего обновления на 215С2 на KN1010 и то как то странное отношение к WEB да и почему клиент не получил адрес DNS от роутера.

    А что там снимать, все работает зацепиться не за что, selftest есть от каждого релиза начиная не знаю с какого времени, все штат но.

    Скрытый текст 
    
По mtkiappd

[I] Mar 24 08:46:18 ndm: Ssh::Manager: security level unchanged.
[I] Mar 24 08:46:18 ndm: Ssh::Manager: bruteforce detection is reconfigured.
[I] Mar 24 08:46:18 ndm: Ftp::Server: security level unchanged.
[I] Mar 24 08:46:18 ndm: Ftp::Server: bruteforce detection is reconfigured.
[I] Mar 24 08:46:18 mtkiappd: Mediatek IAPP daemon v1.10 started on DS interface br0 
[I] Mar 24 08:46:18 ndm: Hotspot::Manager: policy "deny" applied to interface "Home".
....
[I] Mar 24 08:46:22 mtkiappd: Mediatek IAPP daemon v1.10 started on DS interface br0 
[I] Mar 24 08:46:22 radvd[542]: version 2.15 started
[I] Mar 24 08:46:22 ndhcps: NDM DHCP server (version 3.2.28) started.
[I] Mar 24 08:46:22 ndm: Network::Interface::Base: "PPPoE0": interface is up.
....
[I] Mar 24 08:55:38 mtkiappd: IAPP daemon: finished 
[E] Mar 24 08:55:39 ndm: Network::Interface::Ethernet: "WifiMaster1/AccessPoint0": interface is a member of Bridge0.
[E] Mar 24 08:55:39 ndm: Network::Interface::Ethernet: "WifiMaster0/AccessPoint0": interface is a member of Bridge0.
[I] Mar 24 08:55:39 ndm: Network::Interface::Rtx::AccessPoint: "WifiMaster0/AccessPoint0": peer isolation disabled.
...
[I] Mar 24 08:55:40 ndm: Http::SslServer: HTTP SSL server started.
[I] Mar 24 08:55:40 ndm: Http::SslServer: SSTP passthrough is disabled.
[I] Mar 24 08:55:40 mtkiappd: Mediatek IAPP daemon v1.10 started on DS interface br0 
[I] Mar 24 08:55:40 ndm: Core::Server: started Session /var/run/ndm.core.socket.
[I] Mar 24 08:55:40 ndm: Core::Session: client disconnected.
[I] Mar 24 08:55:40 ndm: Http::SslServer: SSL server is listening.
[I] Mar 24 08:55:41 ndhcps: NDM DHCP server (version 3.2.28) started.


    <process id="Bridge0 IAPP">
        <name>mtkiappd</name>
        <arg>-e</arg>
        <arg>br0</arg>
        <arg>-wi</arg>
        <arg>ra0</arg>
        <arg>-k</arg>
        <arg>**********</arg>
        <state>S (sleeping)</state>
        <pid>1579</pid>
        <ppid>192</ppid>
        <vm-size>1108 kB</vm-size>
        <vm-data>172 kB</vm-data>
        <vm-stk>136 kB</vm-stk>
        <vm-exe>20 kB</vm-exe>
        <vm-lib>756 kB</vm-lib>
        <vm-swap>0 kB</vm-swap>
        <threads>1</threads>
        <fds>10</fds>
        <statistics>
            <interval>30</interval>
            <cpu>
                <now>1131.701372</now>
                <min>0</min>
                <max>0</max>
                <avg>0</avg>
                <cur>0</cur>
            </cpu>
        </statistics>
        <service>
            <configured>yes</configured>
            <alive>yes</alive>
            <started>yes</started>
            <state>STARTED</state>
        </service>
    </process>

interface WifiMaster1/AccessPoint0
    rename AccessPoint_5G
    ....
    rrm
    ft mdid NN
    ft otd
    ft enable
    up

     

    Так же попробую повторить данную ошибку еще раз.

    Не отвечает WEB

    в 2.15

    Опубликовано

    Столкнулся на релизе 215С202 KN1010 роутер2 не отвечает на обращение 192.168.1.1 - страница чистая. Система как бы работает, т.е. есть вход в cli, удалось выцепить по dmesg

    Скрытый текст 
    
Роутер2

fastvpn: bind table cleared
fastvpn: bind table cleared
fastvpn: bind table cleared
fastvpn: bind table cleared
do_page_fault(): sending SIGSEGV to mtkiappd for invalid write access to 0042c45c
epc = 771246e8 in libuClibc-1.0.31.so[770c3000+b5000]
ra  = 77124668 in libuClibc-1.0.31.so[770c3000+b5000]
fastvpn: bind table cleared
fastvpn: bind table cleared
fastvpn: bind table cleared
fastvpn: bind table cleared

    17151 root      1108 S    /bin/mtkiappd -e br0 -wi ra0 -k **********

    Как бы все на месте из служб.

    Два роутера в схеме роуминга по 5GHz на роутере1 производилась настройка 5GHz - power параметра, после чего такой бзик. Клиент по Wi-FI подключается IP адрес получен, IP шлюз получен, DSN IP не получен.

    Перезапуск роутера2 вопрос решен.

    USB 3.0 device supports USB Attached SCSI (UAS) Protocol

    в Развитие

    Опубликовано

    Возможно в перспективе для 4.9 на проце 7621 поддержка данного device supports USB Attached SCSI (UAS) и сможет ли он проц осилить или поднять текущие скорости USB3 для роутера.

    Есть упоминания

    Скрытый текст

    https://bugs.openwrt.org/index.php?do=details&task_id=1637 

    
[ 0.000000] Linux version 4.14.50 (buildbot@builds-03.infra.lede-project.org) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r6984-fa0275b)) #0 SMP Fri Jun 22 10:22:57 2018 [ 0.000000] SoC Type: MediaTek MT7621 ver:1 eco:3 [ 0.000000] bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 0001992f (MIPS 1004Kc)
...
[   11.153260] kmodloader: loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
[   11.407918] SCSI subsystem initialized
[   11.442899] usbcore: registered new interface driver usb-storage
[   11.455482] scsi host0: uas
[   11.459086] xhci-mtk 1e1c0000.xhci: ERROR Transfer event for unknown stream ring slot 1 ep 4
[   11.467505] xhci-mtk 1e1c0000.xhci: @000000000f78b190 0e9ae000 00000000 05000000 01058001
[   11.475647] xhci-mtk 1e1c0000.xhci: ERROR Transfer event for unknown stream ring slot 1 ep 6
[   11.484046] xhci-mtk 1e1c0000.xhci: @000000000f78b1a0 0e9ae100 00000000 05000000 01078001
[   32.575006] scsi 0:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[   32.582562] scsi 0:0:0:0: tag#0 CDB: opcode=0x12 12 00 00 00 24 00
[   32.588806] xhci-mtk 1e1c0000.xhci: Mismatch between completed Set TR Deq Ptr command & xHCI internal state.
[   32.598592] xhci-mtk 1e1c0000.xhci: ep deq seg = 8ea5ef00, deq ptr = aea6b010
[   33.684978] scsi host0: uas_eh_device_reset_handler FAILED to get lock err -16
[   33.692180] scsi 0:0:0:0: Device offlined - not ready after error recovery
[   33.699447] usbcore: registered new interface driver uas
[   33.705098] kmodloader: done loading kernel modules from /tmp/overlay/upper/etc/modules-boot.d/*
...
[  161.234025] xhci-mtk 1e1c0000.xhci: Cannot set link state.
[  161.239536] usb usb2-port1: cannot disable (err = -32)
[  161.244695] usb 2-1: USB disconnect, device number 2
[  161.249997] xhci-mtk 1e1c0000.xhci: Mismatch between completed Set TR Deq Ptr command & xHCI internal state.
[  161.259783] xhci-mtk 1e1c0000.xhci: ep deq seg = 8ea5e680, deq ptr = af7fc010
[  173.723928] usb 2-1: new SuperSpeed USB device number 3 using xhci-mtk
[  173.758634] scsi host0: uas
[  173.762521] xhci-mtk 1e1c0000.xhci: ERROR Transfer event for unknown stream ring slot 1 ep 4
[  173.770987] xhci-mtk 1e1c0000.xhci: @000000000f78b400 0e9ae200 00000000 05000000 01058001
[  173.779174] xhci-mtk 1e1c0000.xhci: ERROR Transfer event for unknown stream ring slot 1 ep 6
[  173.787585] xhci-mtk 1e1c0000.xhci: @000000000f78b410 0e9ae100 00000000 05000000 01078001
[  195.773489] scsi 0:0:0:0: tag#0 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN
[  195.781053] scsi 0:0:0:0: tag#0 CDB: opcode=0x12 12 00 00 00 24 00
[  195.787337] xhci-mtk 1e1c0000.xhci: Mismatch between completed Set TR Deq Ptr command & xHCI internal state.
[  195.797126] xhci-mtk 1e1c0000.xhci: ep deq seg = 8f7fde80, deq ptr = ae9ca010
[  196.863444] scsi host0: uas_eh_device_reset_handler FAILED to get lock err -16
[  196.870659] scsi 0:0:0:0: Device offlined - not ready after error recovery
...

     

     

    Технология "802.11k/r/v roaming" пояснения

    в Обмен опытом

    Опубликовано

    4 минуты назад, JIABP сказал:

    Как раз в воскресенье поеду обновлять свои 3 железки до 2.15, переконфигурирую свой псевдо-роуминг на нативный с захватом точек (гига 3 головной и 2 штуки Keenetic Air в режиме точек) и скажу. Одна беда - iPhone 5S и 6, для которых это делается не поддерживает r. Но всё равно посмотрим как оно выглядит.

    Если не трудно то отпишитесь по результатам.

    Технология "802.11k/r/v roaming" пояснения

    в Обмен опытом

    Опубликовано

    9 часов назад, JIABP сказал:

    iPhone 5S/6/7

    Все это хорошо только

    Цитата

    .... Если клиент решает что это ему подходит, он отвечает кодом 0 и вскоре сам быстро перемещается (особенно быстро по FT). Иногда он решает что это ему не подходит и отвечает любым ненулевым кодом. Причина может быть любая, у Apple своя логика, у Android своя. Android обычно отвечает отказом .....

    Только каждый реализует это по своему. Если есть возможность попробуйте проверить на KN1010/Giga 3/Air

    2.15.C.1 реализация Band Steering

    в 2.15

    Опубликовано · Изменено пользователем vasek00

    10 часов назад, Sergey Zozulya сказал:

    не могли бы вы описать, как работает роуминг при такой настройке: 

    80211.thumb.png.55537147cc4ccd962c57dc27ae82d1bd.png

    BTS это, согласно вашим постам выше, вспомогательный механизм Band Steering для клиентов с поддержкой 11k/v, который мягко помогает им определиться с бэндом. Но если BS полностью отключен, как на скриншоте выше, то как в этом случае работает включенный BTS?

    В 5GHz с моим клиентом при проверке работает ОК. Пост открыть по стрелке.

     

    Технология "802.11k/r/v roaming" пояснения

    в Обмен опытом

    Опубликовано

    Релизы 215С1 проверка миграции клиента между двумя роутерами на 5GHz 

    Клиент----5GHz-----KN1810-----5GHz------ExtraII------5GHz------Клиент

    KN18 в точке1, ExtraII в точке2 (дальности между ними чисто символическая просто для проверки миграции клиента между роутерами). Линк между роутерами 527Мбит ( по ExtraII ) и 468Мбит ( по KN1810 ) 

    "txrate": 351, "rxrate": 526, "mode": "11ac", "gi": 800, "rssi": -67, "mcs": 4, "txss": 2, "ebf": false, "mu": false

    На KN18 и ExtraII включено :
    - Роуминг 802.11r (FT)
    - совместимость с FT over the DS
    - Управление BSS-окружением 802.11k/v
    - BandSteering выключен

    SSID на роутерах один только разные каналы 52 и 36.

    1. При перемещение клиента от KN18 точка1 в сторону ExtraII точка2 => клиент переключился на ExtraII (последний rssi который видел для KN18 был равен -73). После переключения клиента на ExtraII rssi=-64, а по KN18 он равен rssi=-75/74

    2. При путешествии обратно т.е. клиент был подключен к ExtraII точка2 перемещался к точке1 ближе к KN18 то клиент вернулся обратно - подключился к KN18, был виден только результат уже когда KN18 rssi=-59/-61 а для ExtraII rssi=-70

    Данную процедуру выполнил несколько раз => миграция данного клиента между роутерами была без вопросов - Sams смарт с поддержкой k/r/v и Android 8.

    По логам что получилось увидеть

    Скрытый текст 
    
KN1810
[I] Mar 20 11:56:41 ndm: Core::Syslog: last message repeated 2 times.
[I] Mar 20 11:56:48 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(хх:хх:хх:хх:хх:be) had associated successfully (FT mode).
[I] Mar 20 11:56:48 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(хх:хх:хх:хх:хх:be) set key done in WPA2/WPA2PSK.
[I] Mar 20 11:56:49 ndhcps: DHCPDISCOVER received  from хх:хх:хх:хх:хх:be.
[I] Mar 20 11:56:49 ndhcps: making OFFER of 192.168.130.17 to хх:хх:хх:хх:хх:be.
[I] Mar 20 11:56:49 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from хх:хх:хх:хх:хх:be.
[I] Mar 20 11:56:49 ndm: kernel: fastvpn: bind table cleared
[I] Mar 20 11:56:49 ndhcps: sending ACK of 192.168.130.17 to хх:хх:хх:хх:хх:be.
[I] Mar 20 11:56:49 ndm: kernel: fastvpn: bind table cleared
Премещение клиента точка переключения
[I] Mar 20 11:59:19 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(хх:хх:хх:хх:хх:be) had deauthenticated by STA (reason: class 3 error - nonassoc STA).
[I] Mar 20 11:59:19 ndm: kernel: fastvpn: cleared binds for хх:хх:хх:хх:хх:be
[I] Mar 20 11:59:26 ndm: kernel: fastvpn: bind table cleared
[I] Mar 20 11:59:56 ndm: Core::Syslog: last message repeated 2 times.
[I] Mar 20 11:59:58 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(e6:18:6b:хх:хх:хх_MAC_ExtraII) set key done in WPA2/WPA2PSK.
[I] Mar 20 12:00:26 ndm: kernel: fastvpn: bind table cleared
[I] Mar 20 12:01:26 ndm: Core::Syslog: last message repeated 2 times.
[I] Mar 20 12:01:36 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(хх:хх:хх:хх:хх:be) FT authenticated successfully.
[I] Mar 20 12:01:36 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(хх:хх:хх:хх:хх:be) had re-associated successfully (FT mode).
[I] Mar 20 12:01:36 ndm: kernel: fastvpn: cleared binds for хх:хх:хх:хх:хх:be
[I] Mar 20 12:01:54 ndm: kernel: fastvpn: bind table cleared
[I] Mar 20 12:02:24 ndm: Core::Syslog: last message repeated 4 times.
[I] Mar 20 12:02:48 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(хх:хх:хх:хх:хх:be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Mar 20 12:02:56 ndm: kernel: fastvpn: bind table cleared
[I] Mar 20 12:04:25 ndm: Core::Syslog: last message repeated 3 times.


ExtraII
....
Переключение клиента с KN18 на ExtraII
[I] Mar 20 11:59:19 wmond: WifiMaster1/AccessPoint0: (MT76x2) STA(хх:хх:хх:хх:хх:be) FT authenticated successfully.
[I] Mar 20 11:59:19 wmond: WifiMaster1/AccessPoint0: (MT76x2) STA(хх:хх:хх:хх:хх:be) had re-associated successfully (FT mode).


хх:хх:хх:хх:хх:be - MAC адрес клиента 
e6:18:6b:хх:хх:хх - MAC роутера ExtraII

    В данном примере четко прослеживается, клиент подключен к KN18, далее при достижение определенного уровня rssi клиент подключается к соседу и ТОЛЬКО после этого прощается со старым роутером (reason: STA is leaving)

     

    Компонент "Контроллер Wi-Fi системы"

    в 2.15

    Опубликовано

    По своему вопросу по WEB ..../controlPanel/wifiSystem после сброса Extra-II к заводским и настройкой получил запись на KN1810 "захват" и как итог в разделе "Модули, входящие в Wi-Fi систему" появилось данное устройство Extra-II, но по логам на KN1810 

    KN1810
[I] Mar 20 15:35:02 ndm: Mws::Controller: enabled.
...
[I] Mar 20 15:35:13 ndm: Mws::MemberList: "e4:18:ExtraII": 2.4 GHz interface detected.
[I] Mar 20 15:35:13 ndm: Mws::MemberList: "e4:18:ExtraII": 5 GHz interface detected.
...
[I] Mar 20 15:41:58 ndm: Mws::RciClient: "50:ff:KN1810": response code 401 (Unauthorized).
[I] Mar 20 15:41:58 ndm: Mws::RciClient: "50:ff:KN1810": Content-Length: 177.
[E] Mar 20 15:41:58 ndm: Mws::RciClient: "50:ff:KN1810": failed to parse JSON response.

Был перезапуск ExtraII
[I] Mar 20 15:45:28 ndm: Core::Init: system ready, core startup time is 33 seconds.
[I] Mar 20 15:45:29 ndm: Http::SslServer: load SSL certificate for domain "e.....4.keenetic.io".
[I] Mar 20 15:45:29 ndm: Http::SslServer: load SSL certificate for domain ".......keenetic.pro".
[I] Mar 20 15:45:29 ndm: Http::SslServer: load SSL certificate for MWS.
[I] Mar 20 15:45:29 ndm: Http::SslServer: HTTP SSL server started.
[I] Mar 20 15:45:29 ndm: Mws::Member: locked.
[I] Mar 20 15:45:29 ndm: Http::SslServer: SSL server is listening.

    Из ходя из того что выше предполагаю фишка была ранее на ExtraII в GUI и certificate, но ошибка "failed to parse JSON response" так и весит.

    Компонент "Контроллер Wi-Fi системы"

    в 2.15

    Опубликовано

    26 минут назад, Mikesk сказал:

    для MWS режим должен быть "точка доступа"

    Проверено - то же самое 

    Мар 20 13:41:28 ndm Mws::Candidate: "e4:18:ExtraII": revisit started.
Мар 20 13:41:28 ndm Mws::Controller: candidate "e4:18:ExtraII" revisit started.
Мар 20 13:41:28 ndm Io::TcpSocket: connected to 192.168.130.200:80.
Мар 20 13:41:28 ndm Mws::RciClient: "e4:18:ExtraII": response code 401 (Unauthorized).
Мар 20 13:41:28 ndm Mws::RciClient: "e4:18:ExtraII": Content-Length: 177.
Мар 20 13:41:28 ndm Mws::RciClient: "e4:18:ExtraII": failed to parse JSON response.
Мар 20 13:41:53 ndm kernel: fastvpn: bind table cleared

     

    Компонент "Контроллер Wi-Fi системы"

    в 2.15

    Опубликовано

    В 25.02.2019 в 10:30, pigovina сказал:

     

    controller.jpg

    Нарвался на такую же ошибку, а точнее "Проверить состояние" т.е. есть роутер в " Модули, доступные для добавления в Wi-Fi-систему".

    Cхема след. 

    ExtraII---5GHz---KN1810

ExtraII Режим «Усилитель»
На KN1810 - "Проверка состояния"

    По логам на KN1810 

    Мар 20 12:35:30 ndm Mws::Candidate: "e4:18:ExtraII": revisit started.
Мар 20 12:35:30 ndm Mws::Controller: candidate "e4:18:ExtraII" revisit started.
Мар 20 12:35:30 ndm Io::TcpSocket: connected to 192.168.130.200:80.
Мар 20 12:35:30 ndm Mws::RciClient: "e4:18:ExtraII": response code 401 (Unauthorized).
Мар 20 12:35:30 ndm Mws::RciClient: "e4:18:ExtraII": Content-Length: 177.
Мар 20 12:35:30 ndm Mws::RciClient: "e4:18:ExtraII": failed to parse JSON response.
Мар 20 12:35:38 ndm kernel: fastvpn: bind table cleared

     

    2.15.C.1.0-0 в релизе

    в 2.15

    Опубликовано · Изменено пользователем vasek00

    30 минут назад, TCH1960 сказал:

    Вы хотите добавить ТД в wifi пул - раз! И у вас на ТД вместо 2.14 - 2.15С1 

    Вы хотите включить дект+ или выключить требуху вроде яндекса и кабинета - Опа! И у вас опять вместо 2.14 - 2.15С1 

    И все это по пункту меню редактирование набора компонент.

    Почему то у Кинетика эти два различных понятия - редактирование набора и апдейт совмещены.

    И это не есть хорошо.

    По DECT выключил так как стал без надобности и т.д. Если нужна уж полная версия про которую вы имеете ввиду, то думаю есть пользователи у которых в отличие от того что я выложил не 98% компонентов а есть все 100%. По поводу 214 релиз нужен был пользователю в котором отсутствует поддержка 802.11v BTM в функции Band Steering (подробности в теме "802.11k/r/v roaming") ......

    В чем фишка, в словосочетании ТД (точка доступа) так у меня оба роутера установлены в режиме "Интернет центра" соединены по LAN 

    Интернет---Роутер1(LAN)---------(LAN)Роутер2

    проблем с компонентами как и функционалом не вижу проблем. Как вы говорите требуха в роде Yandex диска включена правда от Entware как и фильтрация через dnsmasq+dnscrypt-proxy и т.д. На обоих роутерах которые выполняют функцию по доступу клиентов в интернет стоят 215С100.

    2.15.C.1.0-0 в релизе

    в 2.15

    Опубликовано

    Только что, Sergei Sporik сказал:

    ....Сделал именно так как вы описали, посажу важных клиентов могущих роуминг в 5G, а остальные пусть сидят в 2,4G. Самый классный вариант. 

    Так по моему с этого и начинают всю настройку (и пишут везде) и после того как поймете как и что получилось то можно как то и усложнить.

    • Лайк 2

    2.15.C.1.0-0 в релизе

    в 2.15

    Опубликовано

    12 минуты назад, Sergei Sporik сказал:

    Клиенты для которых мне нужна миграция 3 штуки - 2 клиента могут v, r и 1 клиент может k. Я еще сегодня поэксперементирую понизив мощности передатчиков 2,4G на обоих кинетиках до 10%. Посмотрю как они сегодня себя поведут. А по поводу "лучше разные SSID на 2,4 и 5GHz и миграция (роуминг) клиентов по 5GHz между ТД" тоже уже мысль в голову приходила. Так сделаю если сегодняшний опыт не увенчается приемлемым для меня успехом. 

    В данном случае нужно найти середину, а первое что сделать если клиент например может показать такое при подключении

    Без имени-2.jpg

    если нет то возможно лучше сначала определиться с уровнями сигналов 2,4 и 5 в нужных точках, потом из ваших проб (у меня например получились два значения так сказать -85 и -75. Можно попробовать убрать мощность на 2,4 например но проценты это уменьшение сигнала на ххДб что-то типа 

    100 - ослабление 0
xx% - ослабление 1Дб
xx% - ослабление 3Дб
...

    Напомню еще из ходя что могут клиенты чтоб правильно сделать настройки на WEB странице

    Скрытый текст

    802.11k - быстрый поиск соседних точек доступа нужен для поддержки клиентов, которые хотят быстро переключаться между точками доступа

    802.11r - протокол реализует технологию хранения ключей шифрования всех точек доступа или он же FT (Fast Transition) в вариантах — Over the Air (OTA) и Over the DS (OTD)

    802.11v (BSS Transition Management) - протокол рекомендует клиенту со стороны Keenetic перейти на смежный диапазон в рамках одного двухдиапазонного роутера (уровень RSSI), но тут клиент сам принимает решение о переходе.

    Роуминг по протоколу 802.11v происходит совместно с правилами Band Steering. Если клиент поддерживает 802.11v, то будет выполняться предложение о переходе в смежный диапазон. Если клиент не поддерживает 802.11v, к нему применяется механизм отключения Band Steering.

    https://help.keenetic.com/hc/ru/articles/360000862539-Бесшовный-роуминг-Wi-Fi

     

    2.15.C.1.0-0 в релизе

    в 2.15

    Опубликовано

    44 минуты назад, enterfaza сказал:

    не-не-не, не надо такого, у меня практически из клиентов все яблоки, пока что с прыжками BS проблем замечено не было, в обе стороны адекватно работает(под адекватно понимается то, что работает как и всегда и изменений не замечено), но создавать из-за этого BS столько точек(2.4; 5; гость) и чтобы они в эфире светились—костыли, хотя да, можно и скрыть точки и бла-бла-бла, но зачем?есть хорошо работающий(в прошлом) BS, у меня и сейчас работает не плохо и BS упрощает организацию единой сети(имени/пароля, частот, канала), тем более многие  и не понимают как подключиться к скрытой сети включив по-глупости скрытие  

    Речь шла о том что у пользователя два роутера (2 - ТД) которые 5GHz, чего там в эфире светиться SSID на 2,4 и SSID на 5GHz (при наличии 2 ТД) ? да и не чего и не куда скрывать не надо (скажу сразу у 95% пользователей не сидит за стенкой первоклассник, который горит желанием попасть к вам в дом.сеть через wi-fi) о каких костылях идет речь ?

    Вопрос только в том в виду наличия в смартфонах мобильной связи (оплата идет абонентка в месяц) то "перепрыгнув" на 2,4 в такой удаленности от ТД что перевесит - мобильный или 2,4. 

    Мобильный_Инет-----Клиент--(5GHz)SSID1(5GHz)---------(5GHz)SSID1(5GHz)--Клиент-----Мобильный_Инет

    не вижу надобности 2,4

     

    • Лайк 1

    2.15.C.1.0-0 в релизе

    в 2.15

    Опубликовано

    55 минут назад, Sergei Sporik сказал:

    ... Какое-то дурацкое решение на мой взгляд. Смысл тогда вообще в этом Band Steering? Можно было в таком случае не покупать 2 Keenetic, а купить более дешевые решения и вообще не думать об этом. ....

    По поводу решения - вы мыслите со своей колокольни на основе своих клиентов, и роутер не знает где вы находитесь на улице или в другом месте, он может судить только по уровням клиента. Вы даже не по минули про своих клиентов могут ли они что-то из k/r/v. Потратьте чуток времени при анализе поведения вашего клиента при разных настройках Band Steering. У меня например нет возврата на 5GHz а с переходом с 5GHz на 2,4 все ОК.

    Имея два роутера Keenetic думаю вообще лучше не использовать Band Steering а лучше разные SSID на 2,4 и 5GHz и миграция (роуминг) клиентов по 5GHz между ТД.

    • Лайк 1

    2.15.C.1 реализация Band Steering

    в 2.15

    Опубликовано · Изменено пользователем vasek00

    Попробую проверить работу на релизе 215С100 (KN1810). Клиент смартфон который при разном имени на SSID для 2.4/5 при подключении к 5GHz может k/r/v. Клиент смарт Android 8.1 пере сканирует эфир Wi-fi 6-7секунд т.е. идя с данным клиентом видно как меняется параметры его подключения.

    Скрытый текст 
    
[I] Mar 19 12:53:01 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully (FT mode).
[I] Mar 19 12:53:02 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 12:53:02 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 12:53:02 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 12:53:02 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 12:53:02 ndhcps: sending ACK of 192.168.130.17 to ....be.
...
[I] Mar 19 12:53:26 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).

     

    Настроил роутер SSID одно имя, уменьшил 5GHz до 10% так что в помещении далеко не ходить и найти место для подходящих уровней при которых должно работать.

    1. роуминг 802.11r(FT) - выкл., Управление BSS - выкл., Band Steering - по умолчанию

    Скрытый текст 
    
В 2м от роутера подключаемся к 5GHz отходим от роутера где клиент перекл. на 2,4 потом возвращаемся к роутеру на первоначальнюю 
точку в 2м. от него. Уровень подключения в 2м. точке 5GHz=-55 2,4GHz=-40/-42.Переключение где-то после уровня на клиенте более -81

Попытка 1
[I] Mar 19 11:30:18 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 11:30:18 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:30:19 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 11:30:19 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 11:30:19 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 11:30:19 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:30:19 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 11:30:35 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:30:47 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:31:02 bndstrg: band steering: client ....be is allowed to connect to 2.4GHz band 
[I] Mar 19 11:31:02 bndstrg: band steering: client ....be is NOT allowed to connect to 5GHz band (Low RSSI: -85) 
[I] Mar 19 11:31:17 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:31:29 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 11:31:29 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:31:40 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 11:31:47 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:32:47 ndm: Core::Syslog: last message repeated 3 times.
[I] Mar 19 11:32:59 bndstrg: band steering: client ....be is allowed to connect to 5GHz band (Good RSSI: -50) 
[I] Mar 19 11:32:59 bndstrg: band steering: client ....be is NOT allowed to connect to 2.4GHz band

Попытка 2
[I] Mar 19 11:38:02 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:38:02 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 11:38:02 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 11:38:02 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:38:02 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 11:38:02 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 11:38:03 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:38:03 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 11:38:03 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 11:38:03 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:40:59 ndm: Core::Syslog: last message repeated 9 times.
[I] Mar 19 11:41:04 bndstrg: band steering: client ....be is allowed to connect to 2.4GHz band 
[I] Mar 19 11:41:04 bndstrg: band steering: client ....be is NOT allowed to connect to 5GHz band (Low RSSI: -85) 
[I] Mar 19 11:41:29 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:43:29 ndm: Core::Syslog: last message repeated 4 times.
[I] Mar 19 11:43:44 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 11:43:44 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:43:55 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 11:44:02 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:44:32 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:44:49 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Mar 19 11:44:56 ndm: kernel: fastvpn: bind table cleared

    Вывод - при подходе в исходную точку клиент не вернулся на 5GHz

    2. роуминг 802.11r(FT) - выкл., Управление BSS - выкл., Band Steering - Предпочтение 5GHz

    Скрытый текст 
    
Клиент в исходной точке и подключился к 5GHz сигнал -52 в 2м от роутера, стал удаляться, на 2,4 переключился и
уровень на клиенте -55. Возвращаюсь в исходнуюю точку в 2м от роутера на 5GHz не захотел, на 2,4 тут уровень -40
Переключение помоему происходит ~-75 на клиенте.

Попытка 1
[I] Mar 19 11:47:31 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 11:47:31 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:47:31 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 11:47:31 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 11:47:32 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 11:47:32 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:47:32 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 11:47:35 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:48:56 ndm: Core::Syslog: last message repeated 3 times.
[I] Mar 19 11:49:25 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 11:49:25 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:49:26 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:49:35 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 11:49:41 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:52:11 ndm: Core::Syslog: last message repeated 5 times.
[I] Mar 19 11:52:26 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Mar 19 11:52:32 ndm: kernel: fastvpn: bind table cleared

Попытка 2
[I] Mar 19 11:52:26 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Mar 19 11:52:32 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:53:32 ndm: Core::Syslog: last message repeated 2 times.
[I] Mar 19 11:53:39 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....bee) had associated successfully.
[I] Mar 19 11:53:39 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:53:40 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 11:53:40 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 11:53:40 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:53:40 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 11:53:40 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 11:54:02 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:54:14 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:54:18 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 11:54:18 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 11:54:28 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 11:54:35 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 11:56:05 ndm: Core::Syslog: last message repeated 3 times.
[I] Mar 19 11:56:25 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Mar 19 11:56:32 ndm: kernel: fastvpn: bind table cleared

    Вывод - при подходе в исходную точку клиент не вернулся на 5GHz

    3. роуминг 802.11r(FT) - выкл., Управление BSS - вкл., Band Steering - по умолчанию

    Скрытый текст 
    
Начинаем от роутера 2м. 5GHz при -55, удаляемся переключился моментально, идем обратно у роутера в 2м на 5GHz не хочет, 
2,4 показывает уровень -40/-42

Попытка 1
[I] Mar 19 12:00:31 ndm: Core::Syslog: last message repeated 5 times.
[I] Mar 19 12:00:55 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 12:00:55 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 12:00:56 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 12:00:56 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 12:00:56 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 12:00:56 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:00:56 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 12:00:59 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:01:32 ndm: Core::Syslog: last message repeated 2 times.
[I] Mar 19 12:02:01 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 12:02:01 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 12:02:02 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:02:12 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 12:02:20 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:04:50 ndm: Core::Syslog: last message repeated 7 times.
[I] Mar 19 12:05:10 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).

Попытка 2, переключение с 5GHz где то после -73 переключился на 2.4GHz

[I] Mar 19 12:06:06 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had associated successfully.
[I] Mar 19 12:06:07 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 12:06:07 ndhcps: DHCPDISCOVER received  from ....be.
[I] Mar 19 12:06:07 ndhcps: making OFFER of 192.168.130.17 to ....be.
[I] Mar 19 12:06:07 ndhcps: DHCPREQUEST received (STATE_SELECTING) for 192.168.130.17 from ....be.
[I] Mar 19 12:06:07 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:06:07 ndhcps: sending ACK of 192.168.130.17 to ....be.
[I] Mar 19 12:06:17 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:06:47 ndm: Core::Syslog: last message repeated 2 times.
[I] Mar 19 12:06:52 bndstrg: band steering: send BTM request to ....be for roam to 2.4GHz band (Low RSSI: -82) 
[W] Mar 19 12:06:52 bndstrg: band steering: WNM client ....be rejected 2.4GHz band (code: 1) 
[I] Mar 19 12:06:52 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had re-associated successfully.
[I] Mar 19 12:06:53 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) set key done in WPA2/WPA2PSK.
[I] Mar 19 12:07:03 wmond: WifiMaster1/AccessPoint0: (MT7615) STA(....be) had been aged-out and disassociated (idle silence).
[I] Mar 19 12:07:11 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had disassociated by STA (reason: STA is leaving or has left BSS).
[I] Mar 19 12:07:11 wmond: WifiMaster0/AccessPoint0: (MT7615) STA(....be) had deauthenticated by STA (reason: class 3 error - nonassoc STA).
[I] Mar 19 12:07:11 ndm: kernel: fastvpn: bind table cleared
[I] Mar 19 12:07:47 ndm: Core::Syslog: last message repeated 2 times.

    Вывод - при подходе в исходную точку клиент не вернулся на 5GHz

    C роуминг 802.11r(FT) - вкл. проверять нет смысла так как были исправления 215С101 и поведение такого клиента k/r/v может на правильно себя повести.

    Во всех тестах переключение с 5GHz происходило, но обратно клиент с 2,4GHz на 5GHz не возвращался.

    • Спасибо 1

    2.15.C.1.0-0 в релизе

    в 2.15

    Опубликовано · Изменено пользователем vasek00

    32 минуты назад, TCH1960 сказал:

    Это все бесполезно - как только он отредактирует список компонент - у него опять будет 15С1 

    К сожалению не нашел механизма остаться на конкретной прошивке.

    Вопрос ЗАЧЕМ РЕДАКТИРОВАТЬ КОМПОНЕНТЫ, или вы придерживаетесь мнения чем их меньше тем проблем меньше, или чем их меньше тем русурсов роутер будет меньше использовать, или чем их меньше тем памяти будет меньше и т.д.?

    Как написано ранее впри всех компонентах работает исправно, на ExtraII аналогично. 😀

    2.15.C.1 реализация Band Steering

    в 2.15

    Опубликовано

    Вопрос к разрботчикам, скорей всего к Padavan

    Суть его в том что в процессе работы над 2.14/2.15 функция "Band Steering" претерпела много изменений и включение поддержки 802.11v BTM а так же наличие клиентов как с 802.11k/r/v так и без них. Возможно ли описать данный процесс более развернуто не так как в 14/02/2019 https://help.keenetic.com/hc/ru/articles/360000849720-Band-Steering где суть метода это отключение клиента от точки доступа при некотором значении rssi.

    Можно как то разрозненное описание на данном форуме в разных темах про "Band Steering"/802.11k/r/v и 802.11v BTM как то в компактном виде описать (если с примерами некоторых логов, то было вообще отлично).

     

    • Спасибо 3

    2.15.C.1.0-0 в релизе

    в 2.15

    Опубликовано · Изменено пользователем vasek00

    10 часов назад, Sergei Sporik сказал:

    Не совсем хочу последнюю 2.14, т.к. в ней не было поддержки 802.11 v. Я хочу чтобы в новой прошивке вернули принцип работы Band Steering как в последней 2.14. И после этого пусть хоть вообще больше не обновляют. Мне больше в этих устройствах ничего не нужно.  

    Для вас :

    релиз 2.15.А.3.0-3 и 2.15.А.4.0-6 (только для KN1810) так как

    Версия 2.15.A.4.0-1:

    • Wi-Fi: реализована поддержка 802.11v WNM BTM (BSS Transition Management)

    Версия 2.15.A.5.0-1:

    • Wi-Fi: реализована поддержка 802.11v BTM в функции Band Steering (подробности в теме "802.11k/r/v roaming")
    • Wi-Fi: исправлены ошибки перехода по 802.11r PMK-R1 на mt7615
    • Wi-Fi: исправлена ошибка инициализации Assoc Response на mt7615

    В прошивке все компоненты за только исключением - USB-video/audio/тюнер, SMB(стоит TSMB)/Общий доступ Apple, USB Plus DSL/DECT/Wi-Max/USB ком.линий, Кабинет/802.1X

    https://cloud.mail.ru/public/MwF8/D2UC7biQ4

    • Лайк 1

    2.15.C.1.0-0 в релизе

    в 2.15

    Опубликовано

    1 минуту назад, r777ay сказал:

    Научите Smart,Console итд , а мы посмотрим

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

    А вы хоть пробовали ?

    2.15.C.1.0-0 в релизе

    в 2.15

    Опубликовано

    1 минуту назад, Sergei Sporik сказал:

    А зачем? Всё работало прекрасно пока новой прошивкой роутеров всё не испоганили.  

    Потому что КЛИЕНТ САМ СЧИТАЕТ на какой частоте ему работать с роутером.

    От роутера нужно только получить данные + если роуминг то состояние окружающего эфиры (параметры ТД которые рядом) и пусть клиент сам решает, а уж если он не может принять решение то это к вендору клиента.

    Хотите что было раньше, то верните прошивку, которая была, какой релиз нужен?

     

    Giga (KN-1010). "Отваливаются" клиенты на 5 ГГц при тестировании iperf

    в 2.15

    Опубликовано · Изменено пользователем vasek00

    3 часа назад, shurings сказал:

    Смысл очень простой. Менялись драйвера. Что-то говорили про ошибку вендора. Что-то говорили про некие исправления. Вы точно знаете на что влияют эти исправления или, что нужно делать в моем случае для избавления от проблемы?

    Ну и раз уж это обновление ко мне пришло на роутер, отчего бы не установить?

    ....
    Выполнил тест на два Андроид устройства с конфигурацией 1х1: Xiaomi Redmi 4pro,Тв-бокс на RTL8821AU. 
    Результаты повторились. Происходит потеря устройствами сети. Результаты такие же как в первом сообщении.

    Если быть внимательным к постам Padavan и к изменениям в ПО то можно понять какие исправления проходят, но часть остается за кадром конечно.

    Я обращал внимание на данную пару клиентов, если вам так интересен данный результат теста то можете сделать тогда еще и так

    KN1010(iperf3 -s)----5GHz----Клиент(iperf3 -c ......)

    Думаю на Тв-бокс на RTL8821AU у вас будет проблема.

×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.

  Я принимаю