А там написано: "Measurements show, that it can achieve about 5 Mbps in both directions, so even streaming is possible."Вот почти полноценный роутер на esp
GitHub - martin-ger/esp_wifi_repeater: A full functional WiFi Repeater (correctly: a WiFi NAT Router)
Прошиваете два (или три) файла и пользуетесь.
До 8 пользователей, скорость до 1 МБайт/сек.
Я прямое соединение в местной интрасети и тестировал с помощью FBENCH. Это и требуется для IoT.@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.
Из этого заявленное вами "до 1 МБайт/сек" является ложью.
Не успел и не хочу ковырять. Просто поглядел реализацию, чтобы сделать на другом WiFi-SoCТак там же исходники есть. Разве нельзя там ограничить мощность передатчика?
Зачем буфер для TCP? Наверное затем, что в TCP-сокет можно передавать без подтверждения максимум столько байт, какой размер своего окна указала удалённая сторона.И при чем тут буфер? Пакет приходит и отсылается. Зачем буфер для этого?
На время невозможности передачи из-за арбитража WiFi - на то есть буфера у самих WiFi дров, а не у LwIP.
Как это отражается на NAT?Зачем буфер для TCP? Наверное затем, что в TCP-сокет можно передавать без подтверждения максимум столько байт, какой размер своего окна указала удалённая сторона.
И в любой момент удалённая сторона может запросить повтор переданных данных с произвольной позиции внутри неподтверждённых данных. Для повтора TCP-стек эти данные должен где-то взять: или из сохранённых в своём буфере неподтверждённых данных, или запросить у клиента стека. Как делает LwIP я не знаю, так как не использовал его, но в моём стеке, сам стек эти данные не хранит (не имеет буферов для сокетов), а при необходимости запрашивает у клиента (управляющего подключениями стека и передающего ему/принимающего от него данные). Возможно что LwIP использует наоборот - первый метод.
PS: Почему-то очень многие программисты забывают, что в TCP-сокет можно передавать порции данных не ожидая подтверждения предыдущих данных.....
... сообщения загрузки удалены ...
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
Ну и что? Это же указывает только сколько максимум можно ему вдуть без подтверждения.У эксплореров размер TCP окна 100..200+ килобайт.
Ну и вдует кто из сети столько. Ему то чего?Ну и что? Это же указывает только сколько максимум можно ему вдуть без подтверждения.
А что у нас то? А у нас ретранслятор пакетов и ему без разницы размеры буферов верхнего уровня, над ip. Предлагаете ему ещё разбирать что там передается и какой программой?Если наш буфер, где мы помним наши передаваемые данные, меньшего размера, то соответственно мы будем передавать не более его размера.
Ну это если конечно нам нужно именно хранить переданные данные. Если клиент может их заново сгенерить с нужной точки истории - тогда хранить не нужно.
Ответ наверно проще, чем задать такой вопросЧитал читал их readme.md так и не понял какой тип nat (из 4-х возможных) у них реализован.
Если symmetric то для VoIP (sip) всё печально, stun-ом обратный адрес не пробить, единственный выход поднимать b2bua со стороны сервера, а от этого как раз хотелось уйти.
Не так всё сложно, если вы этими протоколами занимаетесь уже долгое времяТак-же сложнее разобраться в именах перечисленных протоколов
Броузер в моем случае совсем не интересен, если нат-ом называют свою поделку которая совсем мимо rfc то решение бесполезное.И почему вы считаете, что "у них" реализован какой-то "тип nat (из 4-х возможных)"? Может это просто огрызок и отсебятина, что вышло, чтобы пропускать стандартные запросы от браузеров...
Там исходники есть.Не так всё сложно, если вы этими протоколами занимаетесь уже долгое время
Я просто хотел услышать был ли у кого нибудь опыт использования этого "репитера" кроме как нагружая его tcp трафиком, стоит ли терять время на тестирование.
LwIP тоже не поддерживает все RFC.Броузер в моем случае совсем не интересен, если нат-ом называют свою поделку которая совсем мимо rfc то решение бесполезное.
ipv6 на ESP32 только, и то опционально. Как ESP-32 примет пакет в 4Терабайта? И вообще как в 802.11 вы представляете инкапсуляцию полных пакетов ipv6?Про ipv6 тоже ни слова, если его нет тоже печально.
Тесты не покажут всё глюки. Исходники не сложные - по ним всё ясно.В общем нужно тестировать самому
Причем тут это? какие 4T?Как ESP-32 примет пакет в 4Терабайта?
Как ни странно в простых wifi-роутерах почему-то есть поддержка ipv6, и внутри сети как ни странно работает.И вообще как в 802.11 вы представляете инкапсуляцию полных пакетов ipv6?
Простые такие - размер такой может быть у пакета ipv6.Причем тут это? какие 4T?
А что бы ей не быть? Ограничен MTU и всё.Как ни странно в простых wifi-роутерах почему-то есть поддержка ipv6, и внутри сети как ни странно работает.
Да. И такое использовал...К сожалению не все wan провайдеры дают ipv6 но на этот случай в некоторых роутерах есть возможность настроить туннельный брокер.
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;
}