очевидный отывет: что-бы всЁ!

п.с.
ну ясен пень, контролировать "потоки" и "зачищать/удалять/сбрасывать зависшие сессии"! памяти то ограничено, а то так и пукан порвать можно!
не пойдет такой ответ?!

не логично... ))


не... надо подробно.

разберём NAT.

-при передачи пакетов из локалки в интернет роутер меняет IP-отправителя и Port-отправителя на свой.
-при передачи пакетов из интернета в локалку происходит обратный процесс...

по поводу НАТ-преобразований - ни чего нового, что вы хотели подчеркнуть/уточнить/выделить/обратить внимание?


пока без ответа, хотелось бы услышать мнения

это не криминал )) это так работает "шарк"

у меня "шарк" подсвечивает повторяющиеся пакеты...

подключился к W5500 с помощью браузера...


видим повторяющиеся пакеты...
просто W5500 подключена к мега328...
а мега328 в этот момент занята прерываниями... и другой работой... поэтому ответить сразу не может))
поэтому браузер повторяет пакеты...
а "шарк" их подсвечивает))


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

Выбираем индустриальные и медицинские источники питания MEAN WELL в открытом исполнении

Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.

Подробнее>>

понял, спасибо

далее... NAT.

-при передачи пакетов из локалки в интернет роутер меняет IP-отправителя и Port-отправителя на свой.
при этом роутер делает соответствующую запись в NAT-таблице: IP-отправителя и Port-отправителя.

после записи в NAT-таблицу (IP-отправителя и Port-отправителя) роутер устанавливает таймер на 120 секунд.
далее... таймер начинает обратный отсчёт)) 119... 118... 117...
пока таймер тикает пакеты из интернета могут проходить в локалку.
когда таймер дотикает до нуля роутер удаляет запись в NAT-таблице (IP-отправителя и Port-отправителя).
после этого пакеты из интернета уже не могут проходить в локалку.
поэтому чтобы "держать порт роутера открытым" надо не реже чем через каждые 120 секунд передавать пакеты из локалки в интернет.

по умолчанию W5500 передаёт пакеты из локалки в интернет каждые 45 секунд.
....
сервер [TCP keep-alive] > w5500 [TCP keep-alive]
сервер [TCP keep-alive] < w5500 [TCP keep-alive]
~45 сек
сервер [TCP keep-alive] > w5500 [TCP keep-alive]
сервер [TCP keep-alive] < w5500 [TCP keep-alive]
~45 сек
....

я обычно в своих приложениях передаю пакеты из локалки в интернет каждые 100 секунд.
....
сервер [TCP keep-alive] > w5500 [TCP keep-alive]
сервер [TCP keep-alive] < w5500 [TCP keep-alive]
~100 сек
сервер [TCP keep-alive] > w5500 [TCP keep-alive]
сервер [TCP keep-alive] < w5500 [TCP keep-alive]
~100 сек
....

передавать пакеты из локалки в интернет чаще чем через каждые 100 секунд нет никакого смысла)).
это лишняя (бесполезная) нагрузка на сеть интернет.


далее... переходим к DoS-атакам на роутер.

роутеру незачем закрывать соединение.

1. во-первых...
если никто корректно не финализировал сессию... то сессия финализируется сама))

Если мы включили свою поделку, она к роутеру подключилась... то поделка должна поддерживать сессию открытой.
....
сервер [TCP keep-alive] > w5500 [TCP keep-alive]
сервер [TCP keep-alive] < w5500 [TCP keep-alive]
~45 сек
сервер [TCP keep-alive] > w5500 [TCP keep-alive]
сервер [TCP keep-alive] < w5500 [TCP keep-alive]
~45 сек
....

Если заглючило её по питанию. Вы её перезапустили, она ещё раз подключилась... то через 120 секунд сессия финализируется сама))
когда таймер дотикает до нуля роутер удаляет запись в NAT-таблице (IP-отправителя и Port-отправителя).
сервер в интернете будет пытаться связаться с w5500, но у него ничего не получится.
т.к. пакеты из интернета больше не попадают в локалку.
сервер повторит ещё несколько попыток...
....
сервер [TCP keep-alive] > w5500 [TCP keep-alive]
~45 сек
сервер [TCP keep-alive] > w5500 [TCP keep-alive]
~45 сек
....
не получив подтверждения от w5500 сервер в интернете сам закроет сессию))
хакеры проиграли))


2. во-вторых...
если хакеры залезли в локалку и открыли 100500 сессий... то все 100500 сессий хакеры должны поддерживать открытыми.
в противном случае через ~120 секунд все 100500 сессий закроются сами))
хакеры проиграли))

3. в-третьих...
а сколько реально мы можем открыть сессий одновременно ?
теоретически максимальное количество одновременно открытых сессий ограничена количеством портов... или размером NAT-таблицы.
это явно меньше чем 100500 сессий...))

а сколько у нас всего портов ?
65536
значит теоретически мы можем открыть 65536 сессий одновременно.


а можно открыть больше чем 65536 сессий одновременно ?
теоретически максимальное количество одновременно открытых сессий НЕ ограничена.
но с оговорками))

каждая новая открытая сессия перезаписывает NAT-таблицу.
при этом старые записи в NAT-таблице затираются... а новые записи в NAT-таблице добавляются...
при этом все 65536 портов в NAT-таблице будут крутится по кругу))
65535... 65534... 65533... 00000... 65535... 65534... 65533...
и так де бесконечности))
поэтому на одном роутере в теории можно открыть даже 100500 сессий... и даже больше))
и все они будут работать.

единственная оговорка - будет потеря пакетов...
и чем больше мы откроем сессий - тем больше будет теряться пакетов.
другими словами - мы просто будет терять трафик.
что в свою очередь приведёт к снижению скорости интернета...
в итоге со стороны будет казаться что роутер "тормозит" и "глючит".
однако все 100500 сессий... будут работать))
да, медленно... да, с повторами пакетов... но всё таки будут работать))
хакеры проиграли))


но это не точно))
тут требуются дополнительные тесты роутера...
надо провести "стресс-тесты" роутера))

...

У вас - это где?
Если что - в TCP только 65534 порта.

ну опечатался, со всеми бывает!
вы, лучше, по теме что ни-будь можете сказать?

чёй то? ))
0000...FFFF - это сколько ?

Как видно:
не опечатался.

По теме здесь говорить нечего - прошло 4 года, топикстартеру думаю эта тема уже давно не интересна.

тему не смотрели, сообщения не читали, но мнение имеете... ну как так можно?
последние 3 страницы какой датой/годом отмечены?

давайте, все-таки, к теме. она сама по себе безгранична и многогранна и для сообщества пригодится!

да.

телефон подключается к компу...

комп подключается к W5500...

телефон подключается к W5500...

в последнем примере мы не можем напрямую посмотреть пакеты в программе Wireshark... потому что в телефоне нет программы Wireshark.))
однако, сами пакеты мы все таки посмотреть можем...
тут нам на помощь пришёл сам W5500... )) который копирует все входящие пакеты с телефона и отравляет на комп...
а уже на компе есть программа Wireshark.

а самое интересное это самодельный модуль))
если из темы "W5500_client+Atmega8_для самых начинающих" выкинуть W5500...
то остаётся "client+Atmega8_для самых начинающих"...
и тут начинается самое интересное))

смотрим сигнал в интернете...

Спойлер

Спойлер

берём Ардуино

Спойлер

собираем схему "client+Atmega8_для самых начинающих"
пишем программу...

Спойлер

нажимаем на кнопочки... всё работает))

разберём подробнее...

Спойлер

Расчётная скорость передачи пакетов у нас должна быть 17.000 пакетов/c. Но на анализаторе мы видим 8.630 пакетов/c.
Половина пектов теряется...
Почему так происходит ?
Потому что мы нарушили требования спецификации https://ru.wikipedia.org/wiki/10BASE-T
У нас ATmega8 передаёт пакеты непрерывно... А согласно спецификации межпакетный интервал должен составлять 9,6 мкс.
https://en.wikipedia.org/wiki/Interpacket_gap
Переделаем всё по стандарту.

Спойлер

Спойлер

Спойлер

Когда ATmega8 не передаёт пакеты, ATmega8 передаёт импульсы NLP (согласно спецификации 10BASE-T).

Спойлер

Всё работает ))
Расчётная скорость передачи пакетов у нас должна быть около 14.000 пакетов/c. На анализаторе видим 14.431 пакетов/c.
Замечательно. Наша ATmega8 передаёт пакеты со скорость 14.431 пакетов/c.
Потерь пакетов нет. Всё работает стабильно.

Преамбула должна быть 8 байт... но на самом деле достаточно 4 байт.

в конце пакета CRC32

Спойлер

Wireshark это не видит. Но оно там есть)).

Далее... усложним схему...
Сделаем Сумматор.

Спойлер

Спойлер

и так работает.
Далее... делаем многоядерный процессор на МК.))

Спойлер

Далее... Синхронизировали работу двух МК.))
Теперь всё работает так:
1- Два МК работают от одного тактового генератора (кварцевый генератор).
2- Два МК выполняют все инструкции синхронно.

Спойлер

Принцип работы синхронизатора простой.))
Перед началом выполнения инструкций первый МК передаёт сигнал синхронизации второму МК.
Второй МК синхронизируется по сигналу синхронизации от первого МК.
В итоге оба МК выполняют все инструкции синхронно.

И нифига не работает))
Видимо для синтеза сигнала Ethernet недостаточно просто синхронизировать выполнений инструкций. Необходимо ещё синхронизировать фазу тактового генератора... с учётом задержек на переключение выводов самого МК...

Добавим в схему фазовый детектор тактового сигнала 20 МГц.

Спойлер

Да, действительно. Фазовый детектор показывает задержку фазы тактового сигнала 20 МГц в несколько наносекунд.

Спойлер

В этом вся проблема.
Решение.
Можно скорректировать тактовый сигнал с помощью LC или RC цепи...
Или можно использовать внешний тактовый генератор.
Другое...

Подключили внешний тактовый генератор на ATmega328.

Спойлер

Фазовый детектор показывает - отклонений фазы тактового сигнала нет.
Теперь два МК типа ATmega8 работают от одного кварцевого генератора синхронно и синфазно. ))
Короче теперь всё работает как надо.

Далее... сделали 4-х ядерный процессор ))

Спойлер

работает))

4-х МК многовато...
используем мультиплексор...

Спойлер

Спойлер

Спойлер

Спойлер

Спойлер

Спойлер

Спойлер

Всё работает))


далее... приёмник.
делаем синхронизацию...
вообще современные заводские интернет приёмники используют PLL синтезатор...

Спойлер

Спойлер

но мы будем делать интернет приёмник как в старом компьютере...

Спойлер

а в старом компьютере используется прямой метод синхронизации...

Спойлер

мы делаем аналог W5500 на Ардуино...

Спойлер

поэтому будем настраивать Ардуино по W5500... включим их в параллель))

Спойлер

нет никакой разницы)) они работают одинаково))

а в чём реально разница ?
ток потребления W5500 = 80 mA
ток потребления Ардуино = 1 мкА
вот и вся разца))

схема Интернет приёмника будет примерно такой...

Спойлер

Спойлер

Спойлер

блок синхронизации...

Спойлер

Спойлер

Спойлер

Спойлер

в блоке синхронизации используем время переключения логических элементов...

Спойлер

Спойлер

Спойлер

работает))

Спойлер

Спойлер

Спойлер

Спойлер

работает))

В итоге получилась такая схема.

Спойлер

Всё работает))

Итого: мы сделали аналог W5500 на Ардуино.))

пробежал по последнему "трактату" (поверхностно)
для чего делалась "задержка"? (можно общ.смысл/ключ.фразы)


подозреваю, что и максимальная дальность, так-же, пропорционально?!

какая "задержка"? там вся схема построена на задержках...

ток потребления W5500 = 80 mA (и не зависит от режима работы).
-в режиме передачи - ток потребления W5500 = 80 mA
-в режиме приёма - ток потребления W5500 = 80 mA
-в режиме простоя - ток потребления W5500 = 80 mA

ток потребления Ардуино = 1 мкА (зависит от режима работы).
-в режиме передачи - ток потребления Ардуино = ~12 mA
-в режиме приёма - ток потребления Ардуино = ~10 mA
-в режиме простоя - ток потребления Ардуино = ~0,1 мкА
поэтому средний ток потребления Ардуино = ~1 мкА

при этом максимальная дальность W5500 и Ардуино одинаковая.
потому что мощность передатчика W5500 и Ардуино одинаковая.))


схема требует доработки...
надо выкинуть лишние детали... заменить МК на логику... и т.д.
короче... ещё есть над чем работать.))

привет! грызу, тут, понимаешь... вопрос по ходу дела:

для приема входных udp-пакетов "мы" использовали прерывание. отлично, все работает!
вопросы:
- будет работать без прерываний, на чистом pool()-механизме?
- какие будут подводные камни?
- на что обратить внимание?!

- будет работать без прерываний, на чистом pool()-механизме? будет. у меня именно так и работает.
- какие будут подводные камни? скорость будет меньше. прерывания обрабатываются сразу. а опрос состояния обрабатывается не сразу... а с задержкой))
- на что обратить внимание?! на скорость)) если скорость не важна то нет никакой разницы.

Ну понятно, так и предполагал, ни чего сверхестественного!

привет! исходные

main-comp - отправляет udp-пакет
avr - отправляет "ответ", типа, подтверждение (тот-же пакет)
все-бы хорошо, но в отладке виден черный ICMP-пакет от main-comp:

непонятки с данным покетом:
запрос отправляется баш-скриптом, типа

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

###!!! UPDATE !!!###
проверяем работу чистым си и ... все работает без проблем
исходные: linux / gcc
параметры ком.строки:

Спойлер

Код:

////////////////////////////////////////////////////////////////////////////////
//
// udp-client for debug atmega328/w5500
//
////////////////////////////////////////////////////////////////////////////////
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>

#define BUFF_SIZE 64

////////////////////////////////////////////////////////////////////////////////
int main(int argc, char *argv[])
////////////////////////////////////////////////////////////////////////////////
{
if(argc != 4)
  {
  fprintf(stderr, "usage: %s <dst-host> <dst-port> <msg-str[%i]>\n", argv[0], BUFF_SIZE);
  exit(EXIT_FAILURE);
  }

const char *srv_host =      argv[1];
const int   srv_port = atoi(argv[2]);
const char *srv_msg  =      argv[3];

int     sockfd;
char    buffer[BUFF_SIZE];
ssize_t sent_size;
struct sockaddr_in server_addr;

//
// UDP-sock
//
if((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0)
  {
  perror("socket creation failed");
  exit(EXIT_FAILURE);
  }

memset(&server_addr, 0, sizeof(server_addr)); // clear

//
// server info
//
server_addr.sin_family  = AF_INET;
server_addr.sin_port    = htons(srv_port);
if(inet_pton(AF_INET, srv_host, &server_addr.sin_addr) <= 0)
  {
  perror("Invalid address/ Address not supported");
  close(sockfd);
  exit(EXIT_FAILURE);
  }

//
// send udp to server
//
sent_size = sendto
  (
  sockfd,
  srv_msg,
  strlen(srv_msg),
  MSG_CONFIRM,
  (const struct sockaddr *) &server_addr,
  sizeof(server_addr));

if(sent_size < 0)
  {
  perror("send to server failed");
  close(sockfd);
  exit(EXIT_FAILURE);
  }

printf("put msg: %s\n", srv_msg);

//
// waiting for server response
//
socklen_t len = sizeof(server_addr);
ssize_t n = recvfrom
  (
  sockfd,
  (char *)buffer,
  BUFF_SIZE,
  MSG_WAITALL,
  (struct sockaddr *) &server_addr,
  &len);

buffer[n] = '\0';

printf("get msg: %s\n", buffer);

close(sockfd);
return 0;
}
////////////////////////////////////////////////////////////////////////////////

Destination unreachable (Port unreachable) - порт закрыт.

Спойлер

баш закрыл порт.
точнее баш его и не открывал... ))
х.з. я с баш не работал.

я работаю с Java...

Спойлер

Спойлер

надо ещё будет сделать VPN...

Спойлер

будет VPN на W5500+Atmega8 ))