Скрыть объявление
На нашем форуме недоступен просмотр изображений для неавторизованных пользователей. Если Вы уже зарегистрированы на нашем форуме, то можете войти. Если у Вас еще нет аккаунта, мы будем рады, если Вы к нам присоединитесь. Зарегистрироваться Вы можете здесь.

Вопрос Повторитель на ESP8266

Тема в разделе "Общие вопросы по esp8266", создана пользователем Controler, 13 апр 2015.

  1. opoffis

    opoffis Новичок

    Сообщения:
    6
    Симпатии:
    0
    я дня 3 изучаю ESP и ардуино и то понимаю что это можно сделать.
    Ютуб в помощь.

    Я смотрю этот сайт вообще бесполезен, помощи ноль.
     
  2. Сергей_Ф

    Сергей_Ф Moderator Команда форума

    Сообщения:
    2.205
    Симпатии:
    229
    tretyakov_sa нравится это.
  3. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.002
    Симпатии:
    1.302
    А там написано: "Measurements show, that it can achieve about 5 Mbps in both directions, so even streaming is possible."
    что равно ~600 килобайт/сек в пике.
    Реальность, при идеальных условиях (+ set speed 160):
    Снимок76.gif
    Ни о каких 5 Mbps и говорить не стоит.
    25..30 килобайт в сек + ужасный пинг. И скорость постоянно колбасит. Какие-то затыки, особенно на UDP.
    Не понятно, почему так мало. Напрямую с роутером, без посредника ESP8266, свисток USB-WiFi дает по WiFi от 8 Mbps в этой программе.
     
    Последнее редактирование: 17 янв 2018
  4. Сергей_Ф

    Сергей_Ф Moderator Команда форума

    Сообщения:
    2.205
    Симпатии:
    229
    @pvvx, я не знаю что вы меряете и как, я смотрю что есть в реале на роликах с YouTube и по Speed test. Выходит в пике до 9 Мбит/с, а в среднем около 7.5. Согласитесь, если файл весит 9 МБ и скачивается за 10 секунд, то поток не будет меньше 7.2 Мбит/с. То что "колбасит" согласен, так буфера то не хватает явно. А для IOT вполне сойдёт, тем более там реализован режим mesh и есть клиент mqtt.

    P.S. Вчера тестировал WeMos D1, было так https://esp8266.ru/forum/threads/problema-pri-proshivke-nuzhna-vasha-pomosch.3093/#post-46741
    забрал её домой. После замечания @pvvx решил перепроверить. На работе есть только WittyCloud - прошил две штуки - скорость , действительно, не поднимается выше 400 КБайт/с, в среднем около 300 КБ/с. Очень странно. Попробую ещё esp-07.
     
    Последнее редактирование: 17 янв 2018
  5. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.002
    Симпатии:
    1.302
    Я прямое соединение в местной интрасети и тестировал с помощью FBENCH. Это и требуется для IoT.
    Но почему-то выходит плохо. Причина не ясна.
    По практике с другими вариантами у ESP8266 трафик на её PHY HT20 с UDP в пике до 1.6 МегБайта/сек, но это чистый проект с CLK CPU 160 MHz и ничем кроме этого не занимается. С TCP, т.к. идет и обратка (передачи и прием) падает до 1.2 МегБайта/сек.
    Если пересчитать, то прием и отсылка выйдет примерно в два раза меньше. Это явно менее 1 Мегабайта в сек.
    Из этого заявленное вами "до 1 МБайт/сек" является ложью. Но это всё фигня - главное почему так сильно проседает тест?
    При задании передачи в десяток пакетов - всё нормально. Если их много - кранты - начинает тормозить (ужасно!).
    И при чем тут буфер? Пакет приходит и отсылается. Зачем буфер для этого?
    На время невозможности передачи из-за арбитража WiFi - на то есть буфера у самих WiFi дров, а не у LwIP.
    Скорее всего ESP8266 теряет пакеты на приеме к ST во время передачи со своей AP... городит коллизии в сети... Надо уточнять... У вас пакеты то идут с промежутками... Всё действо то происходит на одном канале. Может вообще просто ESP перегревается и тротлит или как всегда уровень передатчика по умолчанию в прошивке стоит на макс и она гонит искажения (такое давно известно, но в прошивке нет настройки уровня передачи, а копаться в defauit/bin - лень).
    В общем в непонятке, почему так - вот и спросил, может кто уже знает что там подпихнуть или ?
     
    Последнее редактирование: 17 янв 2018
  6. Сергей_Ф

    Сергей_Ф Moderator Команда форума

    Сообщения:
    2.205
    Симпатии:
    229
    Продолжил тестирование. Откопал ESP8266-Pro от RobotDyn. Выдала те же 0,9 МБайт/с, в пиках 1.1 МБайт. Ролик в 1080 с YouTube шёл минут 10, в шторке скорость колебалась от 1.5 Мбайт/с до 20 КБайт/с.


    Непонятно почему у WittyCloud такая просадка. Проверить ESP-07 не удалось, подал на него питание с USB - он прошился, и даже работал (оказалось там 4.61 В всего), вроде как работал, но при попытки работы как роутера он перегружался. То что лажанулся понял только потом. Городить ему питание лень.




    вот не правда ваша, дяденька. Точно до 1 МБайт/с! Попробуйте доказать что болеее :)



    Так там же исходники есть. Разве нельзя там ограничить мощность передатчика?
     
    Последнее редактирование: 17 янв 2018
  7. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.002
    Симпатии:
    1.302
    Не успел и не хочу ковырять. Просто поглядел реализацию, чтобы сделать на другом WiFi-SoC :)
    Тогда и можно будет сравнить, да покопаться.
     
  8. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.002
    Симпатии:
    1.302
    Попробовал один в один, кинул прямо код в RTL8711AM, и получил:
    5..6 Mbit/sec при размере данных в пакете 1460 байт и 2..3 Mbit/sec при 512 байтах (немного болтает скорость из-за посторонней загрузки канала WiFi другими устройствами, но не просаживает всю сеть как у ESP8266).
    Снимок77.gif
    Это ещё более делает непонятным, почему у ESP8266 при постоянном потоке 20..30 кбит...

    PS: (!) Код в указанной GitHub - martin-ger/esp_wifi_repeater: A full functional WiFi Repeater (correctly: a WiFi NAT Router) имеет более десятка ошибок. Куча не инициализированных указателей, назначеннеы процедуры с выходным значением, а стоят return; без значений, вместо break; иногда также стоят return;... Видимо warnig-и отключены наглухо по инициативе Espressif. Если их включить, то ни один проект или пример от Espressif не собирается.
    В общем замучаетесь собирать проект.
     
    Последнее редактирование: 18 янв 2018
  9. rst

    rst Читатель

    Сообщения:
    253
    Симпатии:
    9
    Зачем буфер для TCP? Наверное затем, что в TCP-сокет можно передавать без подтверждения максимум столько байт, какой размер своего окна указала удалённая сторона.
    И в любой момент удалённая сторона может запросить повтор переданных данных с произвольной позиции внутри неподтверждённых данных. Для повтора TCP-стек эти данные должен где-то взять: или из сохранённых в своём буфере неподтверждённых данных, или запросить у клиента стека. Как делает LwIP я не знаю, так как не использовал его, но в моём стеке, сам стек эти данные не хранит (не имеет буферов для сокетов), а при необходимости запрашивает у клиента (управляющего подключениями стека и передающего ему/принимающего от него данные). Возможно что LwIP использует наоборот - первый метод.
    PS: Почему-то очень многие программисты забывают, что в TCP-сокет можно передавать порции данных не ожидая подтверждения предыдущих данных..... :confused:
     
  10. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.002
    Симпатии:
    1.302
    Как это отражается на NAT? :confused:
    Пакет пришел от интерфейса WiFi дров к LwIP. LwIP имеет два netif - на AP и ST. Разбираем какой интерфейс задействован по данным IP из пакета. Меняем и передает пакет обратно к дровам WiFi.
    На этом всё.
    Буфер на пакет? :) MTU?
    А нужен ли он даже? Пришедшие данные уже положены в RAM и там надо изменить только заголовок и отдать это передатчику. У дров WiFi свои буфера. Если они не успевают передавать пришедшее, то тогда беда. Что и наблюдается на ESP.
    Каковы причины такому:
    Приемник и передатчик работают на одном канале. При этом там внешняя AP и внутренняя у ESP + клиент. Если ESP не шарит с арбитражем, не учитывает внешнюю AP, а своей творит колизии в эфире, то что получим?
    Полнофункциональная AP учитывает и BT передатчики.

    У эксплореров размер TCP окна 100..200+ килобайт. :p

    + Рабочий пример:
    Пробуем перегрузить интерфейс запросами с компа через USB-WiFi свисток.
    Подключаемся к AP, заходим к примеру на Яндекс. Нужна старица с большим кол-вом файлов и быстрым доступом. Жмем непрерывно F5 или CTL+F5 (очистка кеш броузера и компа). Получаем:
    Код (Text):
    1. ... сообщения загрузки удалены ...
    2. Interface 0 IP address : 192.168.1.129
    3. Station ip: 192.168.1.129
    4. NetBIOS init, interface 0: 'RTL871X0' 1: 'RTL871X1'
    5. SNTP start.
    6. WEB: init port 80
    7. RTL8195A[Driver]: skb_unavailable=2 in last 2 seconds
    8. RTL8195A[Driver]: skb_unavailable=9 in last 2 seconds
    9. RTL8195A[Driver]: skb_unavailable=96 in last 2 seconds
    10. RTL8195A[Driver]: skb_unavailable=69 in last 2 seconds
    11. RTL8195A[Driver]: skb_unavailable=47 in last 2 seconds
    12. RTL8195A[Driver]: skb_unavailable=129 in last 2 seconds
    13. RTL8195A[Driver]: skb_unavailable=26 in last 2 seconds
    14. RTL8195A[Driver]: skb_unavailable=10 in last 2 seconds
    15. RTL8195A[Driver]: skb_unavailable=23 in last 2 seconds
    16. RTL8195A[Driver]: skb_unavailable=223 in last 2 seconds
    Видим, что дрова WiFi не справляются и скипают пакетики, предупреждая об этом в консоль RTL...
    Если это делать с сайтом данного форума, то такого нет - к нему пинг долгий и переполнений не возникает...
     
    Последнее редактирование: 23 янв 2018
  11. rst

    rst Читатель

    Сообщения:
    253
    Симпатии:
    9
    Ну и что? Это же указывает только сколько максимум можно ему вдуть без подтверждения.
    Если наш буфер, где мы помним наши передаваемые данные, меньшего размера, то соответственно мы будем передавать не более его размера.
    Ну это если конечно нам нужно именно хранить переданные данные. Если клиент может их заново сгенерить с нужной точки истории - тогда хранить не нужно.
     
  12. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.002
    Симпатии:
    1.302
    Ну и вдует кто из сети столько. Ему то чего? :)
    Вы собрались это всё буферизировать в ESP? :eek:
    Ну берем две открытых страницы в Эксплорере... Обычно с одной они тянут в пяток потоков (или больше - зависит от кол-ва файлов контекста страницы и т.д.....)
    5*200*2 = 2 Мегабайта на буфер. :)
    А что у нас то? А у нас ретранслятор пакетов и ему без разницы размеры буферов верхнего уровня, над ip. Предлагаете ему ещё разбирать что там передается и какой программой? :)
    LwIP и тем более TCP стек в данном деле участия не принимают. От LwIP требуется только интерфейс netif, для определения транслируемых ip.
    Процедура подмены ip: port условно встроена между LwIP и дровами WiFi. Транслируемый (принятый) пакет LwIP не отдается, а идет на передачу дровам WiFi. Только если пакет имеет назначение на внутренний ip, то он туда и передается (отдается LwIP) и там уже ваша программа, если есть таковая с открытым портом TCP, разбирается с приемом и передачей только своих данных.

    Тут надо разбирать как и когда должен следовать beacon на одном канале у вторичной AP (работающей на одном канале с другой ближайшей AP) для создания правильного арбитража...
    Клиенты могут передавать только в промежутке паузы между приемом beacon. Если вторая AP лепит свои beacon когда захочет (в середине паузы другой AP) - то какой пакет придет? Битый, коллизия....

    В итоге и сделали режим "репитера" в WiFi, который соображает как ведет арбитраж клиентов каждая дублирующая AP (повторители)... И падение скорости трафика при этом тоже в 2 раза.
     
    Последнее редактирование: 23 янв 2018
  13. Алексей.

    Алексей. Авторитетный участник сообщества

    Сообщения:
    561
    Симпатии:
    64
    Читал читал их readme.md так и не понял какой тип nat (из 4-х возможных) у них реализован.
    Если symmetric то для VoIP (sip) всё печально, stun-ом обратный адрес не пробить, единственный выход поднимать b2bua со стороны сервера, а от этого как раз хотелось уйти.
     
  14. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.002
    Симпатии:
    1.302
    Ответ наверно проще, чем задать такой вопрос :)
    Это к тому, что разобраться что требуется stun-у для его поддержки сложнее, чем запустить прошивку и проверить. Так-же сложнее разобраться в именах перечисленных протоколов, чем описать какой бит изменен в кадре :)
    И почему вы считаете, что "у них" реализован какой-то "тип nat (из 4-х возможных)"? Может это просто огрызок и отсебятина, что вышло, чтобы пропускать стандартные запросы от браузеров...
    VoIP тут вообще не прокатит, т.к. на ESP8266 ужасный бьющий пинг...

    Может вы ответите на простой вопрос? Какие типы пакетов передает драйвер WiFi Espressif к LwIP?
    Какая фильтрация типов и по каким параметрам встроена или её вообще нет?
    Т.е. это подобие сниффера или он выделяет только пакеты ip4? ip6 он отдает (кто занимается фрагментацией больших пакетов)? Какова буферизация приемных и передаваемых данных? Ну и т.д. - мульон вопросов и полное отсутствие описания.
    Может из-за Излишняя сетевая буферизация — Википедия и происходит тормоз у ESP8266?

    (У дров WiFi от Ameba для RTL серии "A" по умолчанию стоит фильтр в дровах WiFi и его надо отключать для данной реализации псевдо-NAT. В данном случае более открытый по исходникам SDK дает свои преимущества и можно посмотреть и узнать что получится, в отличии от реализаций у ESP. Фильтр откидывает пакеты не обрабатываемые LwIP и не приходящиеся на местные подсети, чтобы укоротить путь обработки и уменьшить потребление...)
     
    Последнее редактирование: 24 янв 2018
  15. Алексей.

    Алексей. Авторитетный участник сообщества

    Сообщения:
    561
    Симпатии:
    64
    Не так всё сложно, если вы этими протоколами занимаетесь уже долгое время :)
    Я просто хотел услышать был ли у кого нибудь опыт использования этого "репитера" кроме как нагружая его tcp трафиком, стоит ли терять время на тестирование.
    Броузер в моем случае совсем не интересен, если нат-ом называют свою поделку которая совсем мимо rfc то решение бесполезное.
    Про ipv6 тоже ни слова, если его нет тоже печально.
    В общем нужно тестировать самому :)
     
  16. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.002
    Симпатии:
    1.302
    Там исходники есть.

    LwIP тоже не поддерживает все RFC.
    ipv6 на ESP32 только, и то опционально. Как ESP-32 примет пакет в 4Терабайта? :) И вообще как в 802.11 вы представляете инкапсуляцию полных пакетов ipv6?
    Тесты не покажут всё глюки. Исходники не сложные - по ним всё ясно.

    Основные непонятности в NAT с всякими проводками broad-multi-cast и спец пакетов c адресаций для местной сети. А вот как раз это и используется в stun-е... Но пока разговор шел о псевдо-NAT пристройке, остальное - это IP_FORWARD опция в LwIP.
    Цена более полноценного роутера не сильно отличается от комплекта ESP (c БП и корпусом), по этому все эти навороты имеют чисто спортивный интерес и не более...
     
    Последнее редактирование: 24 янв 2018
  17. Алексей.

    Алексей. Авторитетный участник сообщества

    Сообщения:
    561
    Симпатии:
    64
    Причем тут это? какие 4T?
    Как ни странно в простых wifi-роутерах почему-то есть поддержка ipv6, и внутри сети как ни странно работает.
    Раскрыть Спойлер

    alex@hp-envy-13:~$ ifconfig
    lo Link encap:Локальная петля (Loopback)
    inet addr:127.0.0.1 Mask:255.0.0.0
    inet6 addr: ::1/128 Scope:Host
    UP LOOPBACK RUNNING MTU:65536 Metric:1
    RX packets:321 errors:0 dropped:0 overruns:0 frame:0
    TX packets:321 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:25361 (25.3 KB) TX bytes:25361 (25.3 KB)

    wlp1s0 Link encap:Ethernet HWaddr 60:6d:c7:e5:23:fb
    inet addr:192.168.4.105 Bcast:192.168.4.255 Mask:255.255.255.0
    inet6 addr: fe80::24ce:3842:ee2f:cbdf/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:5437 errors:0 dropped:0 overruns:0 frame:3452
    TX packets:3025 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:6923663 (6.9 MB) TX bytes:678014 (678.0 KB)
    Interrupt:17

    alex@hp-envy-13:~$ ping6 fe80::cabe:19ff:fed3:7376%wlp1s0
    PING fe80::cabe:19ff:fed3:7376%wlp1s0(fe80::cabe:19ff:fed3:7376) 56 data bytes
    64 bytes from fe80::cabe:19ff:fed3:7376: icmp_seq=1 ttl=64 time=45.9 ms
    64 bytes from fe80::cabe:19ff:fed3:7376: icmp_seq=2 ttl=64 time=69.3 ms
    64 bytes from fe80::cabe:19ff:fed3:7376: icmp_seq=3 ttl=64 time=90.8 ms
    ^C
    --- fe80::cabe:19ff:fed3:7376%wlp1s0 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2002ms
    rtt min/avg/max/mdev = 45.914/68.712/90.874/18.361 ms
    alex@hp-envy-13:~$ ping6 fe80::24ce:3842:ee2f:cbdf%wlp1s0
    PING fe80::24ce:3842:ee2f:cbdf%wlp1s0(fe80::24ce:3842:ee2f:cbdf) 56 data bytes
    64 bytes from fe80::24ce:3842:ee2f:cbdf: icmp_seq=1 ttl=64 time=0.108 ms
    64 bytes from fe80::24ce:3842:ee2f:cbdf: icmp_seq=2 ttl=64 time=0.095 ms
    64 bytes from fe80::24ce:3842:ee2f:cbdf: icmp_seq=3 ttl=64 time=0.119 ms
    ^C
    --- fe80::24ce:3842:ee2f:cbdf%wlp1s0 ping statistics ---
    3 packets transmitted, 3 received, 0% packet loss, time 2046ms
    rtt min/avg/max/mdev = 0.095/0.107/0.119/0.012 ms

    На буке пингонул соседний ПК и свой по ipv6 :)

    К сожалению не все wan провайдеры дают ipv6 но на этот случай в некоторых роутерах есть возможность настроить туннельный брокер.
     
  18. pvvx

    pvvx Активный участник сообщества

    Сообщения:
    9.002
    Симпатии:
    1.302
    Простые такие - размер такой может быть у пакета ipv6.
    Откройте хоть вики: Пакет IPv6 — Википедия
    IPv6-пакеты никогда не фрагментируются маршрутизаторами. Пакеты, чей размер превышает MTU сетевого подключения уничтожаются и отправителю посылается сообщение Packet too Big (ICMPv6 тип 2).

    А что бы ей не быть? Ограничен MTU и всё.
    Да. И такое использовал...
    Но тут про ESP8266 - какие у него ipv6? Он в базе не поддерживает ipv6 - используется только ip структура на 4 байта везде. Берите и переписывайте всё там, потом включите поддержку ipv6 в LwIP. В ESP-32 - опционально.

    Весь NAT тут, в этом файле, это вставка при IP_FORWARD к LwIP: esp-open-lwip/ip.c at sdk-1.5.0 · martin-ger/esp-open-lwip · GitHub
    И там переназначаются ip и port
    и далее
    /* transmit pbuf on chosen interface */
    netif->output(netif, p, &current_iphdr_dest);
    return;

    Т.е. входящий пакет идет на вывод обратно в дрова (ну если не местный).


    И все входящие пакеты (ip_input()) вот так:
    Код ( (Unknown Language)):
    1. if (IPH_V(iphdr) != 4) {
    2. LWIP_DEBUGF(IP_DEBUG | LWIP_DBG_LEVEL_WARNING, ("IP packet dropped due to bad version number %"U16_F"\n", IPH_V(iphdr)));
    3. ip_debug_print(p);
    4. pbuf_free(p);
    5. IP_STATS_INC(ip.err);
    6. IP_STATS_INC(ip.drop);
    7. snmp_inc_ipinhdrerrors();
    8. return ERR_OK;
    9. }
    Если не "4" - то долой.
     
    Последнее редактирование: 24 янв 2018
    opoffis нравится это.
  19. chip12

    chip12 Новичок

    Сообщения:
    10
    Симпатии:
    0
    Никто не разбирал эту прошивку про которую идёт речь, martin-ger/esp_wifi_repeater, по частям? По умолчанию в репиторе TTL=255, как поменять на другой?
    И ещё интересное заметил по скорости, прошиваю, запускаю, соединяю с одним устройством, скорость порядка 0.3-0,9 (МБайт/с), подключаю ещё одно устройство по WiF, замеряю скорость, и она совпадает с заявленной в районе 3-5(МБайт/с.) . Может совпадение, не думаю. )
     

Поделиться этой страницей