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

[opoffis]

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

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

 

[Сергей_Ф]

Вот почти полноценный роутер на esp
GitHub - martin-ger/esp_wifi_repeater: A full functional WiFi Repeater (correctly: a WiFi NAT Router)
Прошиваете два (или три) файла и пользуетесь.
До 8 пользователей, скорость до 1 МБайт/сек.

 

[pvvx]

Вот почти полноценный роутер на esp
GitHub - martin-ger/esp_wifi_repeater: A full functional WiFi Repeater (correctly: a WiFi NAT Router)
Прошиваете два (или три) файла и пользуетесь.
До 8 пользователей, скорость до 1 МБайт/сек.

А там написано: "Measurements show, that it can achieve about 5 Mbps in both directions, so even streaming is possible."
что равно ~600 килобайт/сек в пике.
Реальность, при идеальных условиях (+ set speed 160):

Ни о каких 5 Mbps и говорить не стоит.
25..30 килобайт в сек + ужасный пинг. И скорость постоянно колбасит. Какие-то затыки, особенно на UDP.
Не понятно, почему так мало. Напрямую с роутером, без посредника ESP8266, свисток USB-WiFi дает по WiFi от 8 Mbps в этой программе.

 

[Сергей_Ф]

@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.

 

[pvvx]

@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.

Я прямое соединение в местной интрасети и тестировал с помощью 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 - лень).
В общем в непонятке, почему так - вот и спросил, может кто уже знает что там подпихнуть или ?

 

[Сергей_Ф]

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


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

Из этого заявленное вами "до 1 МБайт/сек" является ложью.

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



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

 

[pvvx]

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

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

 

[pvvx]

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

Это ещё более делает непонятным, почему у ESP8266 при постоянном потоке 20..30 кбит...

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

 

[rst]

И при чем тут буфер? Пакет приходит и отсылается. Зачем буфер для этого?
На время невозможности передачи из-за арбитража WiFi - на то есть буфера у самих WiFi дров, а не у LwIP.

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

 

[pvvx]

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

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

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

+ Рабочий пример:
Пробуем перегрузить интерфейс запросами с компа через USB-WiFi свисток.
Подключаемся к AP, заходим к примеру на Яндекс. Нужна старица с большим кол-вом файлов и быстрым доступом. Жмем непрерывно F5 или CTL+F5 (очистка кеш броузера и компа). Получаем:

... сообщения загрузки удалены ...
Interface 0 IP address : 192.168.1.129
Station ip: 192.168.1.129
NetBIOS init, interface 0: 'RTL871X0' 1: 'RTL871X1'
SNTP start.
WEB: init port 80
RTL8195A[Driver]: skb_unavailable=2 in last 2 seconds
RTL8195A[Driver]: skb_unavailable=9 in last 2 seconds
RTL8195A[Driver]: skb_unavailable=96 in last 2 seconds
RTL8195A[Driver]: skb_unavailable=69 in last 2 seconds
RTL8195A[Driver]: skb_unavailable=47 in last 2 seconds
RTL8195A[Driver]: skb_unavailable=129 in last 2 seconds
RTL8195A[Driver]: skb_unavailable=26 in last 2 seconds
RTL8195A[Driver]: skb_unavailable=10 in last 2 seconds
RTL8195A[Driver]: skb_unavailable=23 in last 2 seconds
RTL8195A[Driver]: skb_unavailable=223 in last 2 seconds

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

 

[rst]

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

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

 

[pvvx]

Ну и что? Это же указывает только сколько максимум можно ему вдуть без подтверждения.

Ну и вдует кто из сети столько. Ему то чего?
Вы собрались это всё буферизировать в ESP?
Ну берем две открытых страницы в Эксплорере... Обычно с одной они тянут в пяток потоков (или больше - зависит от кол-ва файлов контекста страницы и т.д.....)
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 раза.

 

[Алексей.]

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

 

[pvvx]

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

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

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

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

 

[Алексей.]

Так-же сложнее разобраться в именах перечисленных протоколов

Не так всё сложно, если вы этими протоколами занимаетесь уже долгое время
Я просто хотел услышать был ли у кого нибудь опыт использования этого "репитера" кроме как нагружая его tcp трафиком, стоит ли терять время на тестирование.

И почему вы считаете, что "у них" реализован какой-то "тип nat (из 4-х возможных)"? Может это просто огрызок и отсебятина, что вышло, чтобы пропускать стандартные запросы от браузеров...

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

 

[pvvx]

Не так всё сложно, если вы этими протоколами занимаетесь уже долгое время
Я просто хотел услышать был ли у кого нибудь опыт использования этого "репитера" кроме как нагружая его tcp трафиком, стоит ли терять время на тестирование.

Там исходники есть.

Броузер в моем случае совсем не интересен, если нат-ом называют свою поделку которая совсем мимо rfc то решение бесполезное.

LwIP тоже не поддерживает все RFC.

Про ipv6 тоже ни слова, если его нет тоже печально.

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

В общем нужно тестировать самому

Тесты не покажут всё глюки. Исходники не сложные - по ним всё ясно.

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

 

[Алексей.]

Как ESP-32 примет пакет в 4Терабайта?

Причем тут это? какие 4T?

И вообще как в 802.11 вы представляете инкапсуляцию полных пакетов ipv6?

Как ни странно в простых 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 но на этот случай в некоторых роутерах есть возможность настроить туннельный брокер.

 

[pvvx]

Причем тут это? какие 4T?

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

Как ни странно в простых wifi-роутерах почему-то есть поддержка ipv6, и внутри сети как ни странно работает.

А что бы ей не быть? Ограничен MTU и всё.

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

Да. И такое использовал...
Но тут про 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()) вот так:

if (IPH_V(iphdr) != 4) {
LWIP_DEBUGF(IP_DEBUG | LWIP_DBG_LEVEL_WARNING, ("IP packet dropped due to bad version number %"U16_F"\n", IPH_V(iphdr)));
ip_debug_print(p);
pbuf_free(p);
IP_STATS_INC(ip.err);
IP_STATS_INC(ip.drop);
snmp_inc_ipinhdrerrors();
return ERR_OK;
}

Если не "4" - то долой.

 

[chip12]

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