Байт отправлено больше чем принято

Байт отправлено больше чем принято

13 Jan 2013 в 04:21

13 Jan 2013 в 04:21 #1

13 Jan 2013 в 04:22 #2

Попробуй новый комп купить, поможет

13 Jan 2013 в 04:23 #3

Возможно какая-то прога обновляется

13 Jan 2013 в 04:25 #4

13 Jan 2013 в 04:26 #5

Прошу реальной помощи.

13 Jan 2013 в 04:26 #6

Есть у меня подозрение на вирусняк, прошу помочь. Вам надо лишь сказать сколько у вас принятых, отправленных пакетов и время подключения. Для этого вам нужно зайти в значок сети справа внизу(адидас короче), нажать ПКМ на вашу сеть и тыкнуть «Состояние».

У меня 2 часа 15 000 000 байт отправлено и 93 000 000 байт принято, чувствую что-то неладное.

торрент клиент забыл закрыть или остановить раздачи?

13 Jan 2013 в 04:27 #7

Все я отключил, на вирусы проверял. Сделал все, что мог.

13 Jan 2013 в 04:30 #8

Есть у меня подозрение на вирусняк, прошу помочь. Вам надо лишь сказать сколько у вас принятых, отправленных пакетов и время подключения. Для этого вам нужно зайти в значок сети справа внизу(адидас короче), нажать ПКМ на вашу сеть и тыкнуть «Состояние».

У меня 2 часа 15 000 000 байт отправлено и 93 000 000 байт принято, чувствую что-то неладное.

всё зависит от продолжительности соединения и его нагрузки

у тебя ничего типо не запущено и трафик мотает?)

1) проверка антивирусом
2) проверка автозагрузки
3) проверка подозрительных процессов
4) переустановка интернет подключения
думаю поможет

Источник

Maximum Transmission Unit (MTU). Мифы и рифы

Maximum transmission unit (MTU) это максимальный объём данных, который может быть передан протоколом за одну итерацию. К примеру, Ethernet MTU равняется 1500, что означает, что максимальный объём данных, переносимый Ethernet фреймом не может превышать 1500 байт (без учёта Ethernet заголовка и FCS — Рис. 1).

Рис. 1

Давайте пробежимся с MTU по уровням OSI:

Layer 2.

Ethernet MTU является частным случаем Hardware MTU. Определение Hardware MTU вытекает из общего определения:
Hardware MTU — это максимальный размер пакета, который может быть передан интерфейсом за одну итерацию (по крайней мере значение указано в спецификациях устройства – по факту некоторые чипсеты поддерживают передачу больших размеров пакетов, чем заявлено). Поэтому если взглянуть на рисунок 1 в отрыве от Ethernet, то получим следующее:

Рис. 2

Замечание: Однако и тут не обойтись без оговорки. Как вы видите, HW MTU (Ethernet MTU в частности) не включает заголовок L2 в себя. Однако это справедливо для IOS и IOS XE, но для IOS XR и JunOS заголовок L2 включен в размер HW MTU – Рис. 3. Эта особенность может привезти к проблемам при установке OSPF neighborship между платформами под управлением IOS(XE) и IOS XR (OSPF требует совпадения MTU в Hello пакетах). Поэтому, при конфигурации MTU для Ethernet интерфейсов, на стороне IOS XR MTU должно быть на 14 байт больше (12 байт src mac+dst mac и 2 байт EtherType). К примеру, MTU в 1500 в Cisco IOS эквивалентно MTU в 1514 для IOS XR.

Рис. 3

Конфигурация и проверка.

Для того что бы изменить MTU на маршрутизаторах под управлением Cisco IOS используется команда интерфейс уровня:

Layer3.

IP MTU определяет максимальный размер пакета с IP заголовком, который может быть передан на данном интерфейсе не прибегая к фрагментации. Зависимость между IP MTU и HW MTU описывается следующей формулой:
IP MTU ≤ HW MTU
Соответственно, когда на интерфейс попадает пакет, превосходящий установленное IP MTU, пакет либо подвергается фрагментации, либо, в случае установленного флага DF (DO NOT Fragment) в IP заголовке, дискардится, а устройство может сгенерировать ICMP сообщение Fragmentation Needed, используемое в механизме path MTU discovery (о нём позже), и отправить его назад отправителю исходного пакета.

Конфигурация и проверка.

Для изменения IP MTU на маршрутизаторах под управлением Cisco IOS используется команда интерфейс уровня:

Вот те раз. Команда ip mtu не видна в show run. Да тут есть интересный нюанс – если ip mtu совпадает с hw mtu, то в выводе show run будет отображаться только hw mtu. Если значения разные то отображаются оба.

Layer 4.

TCP Maximum Segment Size (MSS) определяет максимальный размер TCP сегмента (без TCP заголовка!), который может быть использован (отправлен/принят) в ходе TCP сессии. Анонс (именно анонс, не хендшейк) размеров TCP MSS происходит во время установки TCP сессии – принимающая сторона анонсирует стороне отправляющей какой размер TCP сегмент она может принять. Соответственно размер TCP MSS может различаться в рамках одной TCP сессии в зависимости от направления.

Рис. 4

Сторона, производящая анонс, высчитывает значение TCP MSS для себя по следующей формуле:
TCM MSS = (IP MTU – [IPHDR + TCPHDR])

Конфигурация.

Тут у нас возможны два сценария – маршрутизатор является транзитным или участником TCP сессии.
1) Транзитное устройство:
Для предотвращения дропа пакетов промежуточным устройством в случае наличия линка с малым MTU, маршрутизатор будет прослушивать TCP SYN пакеты и подменять значения MSS анонсируемые конечным устройством. Что приведет к отправке пакетов меньшей величины конечным устройством и вуаля – проблема с дропами на линке с малым MTU упреждена.

2) Терминирующее устройство:
Здесь всё просто – маршрутизатор является участником TCP сессии и мы можем установить принудительно, размер MSS который он будет анонсировать.

Кажется всё? Нет, не всё. Вспоминаем про MPLS. Вспоминаем… Закончили вспоминать, переходим к рассмотрению.

Layer 2,5. MPLS.

Рис. 5

MPLS MTU определяет максимальный размер маркированного (кто знает как лучше переводиться Labeled прошу подсказать в комментах) IP пакета. В случае, если размер маркированного пакета превышает MPLS MTU, то пакет либо фрагментируется, либо, при наличии установленного в IP заголовка флага с DF bit, дропается (пока логика как и при превышении IP MTU), с возможной отправкой ICMP сообщения Fragmentation Needed.

Замечание: Вот тут дела обстоят немного по другому, по сравнению c IP MTU. В MPLS сети промежуточный узел может и не иметь маршрута к отправителю пакета, поэтому вместо того что бы слать ICMP сообщение отправителю напрямую, оно инкапсулируется с тем же стеком меток (label stack), что и исходный пакет, и отправляется по его же пути следования. Достигая Egress LSR (конечного MPLS маршрутизатора для данного LSP – за ним уже IP сеть без меток), который знает ip маршруты к узлу отправителя, ICMP сообщение Fragmentation Needed «разворачивается» им, инкапсулируется необходимыми заголовками и отправляется назад в MPLS сеть к отправителю оригинального пакета. Поведение аналогично с TTL Expired, да и в целом скорее относиться к теме MPLS, а не MTU. Поэтому кто не знаком с процессом — www.google.kg/?gws_rd=ssl#q=mpls+ttl+expired

Что здесь ещё интересного? MPLS MTU может быть больше HW MTU (поэтому на Рис. 3 HW MTU частично обозначено пунктиром). При этом IOS выдаст варнинг, но в большинстве случаев будет работать (зависит от чипсета интерфейса) и успешно пропускать по крайней мере baby-giant фреймы. А в иной раз можно получить дроп пакетов, повреждение данных, и сто лет без урожая.

Конфигурация и проверка.

Замечание: MPLS MTU отображается в running конфиге, также как и IP MTU — только в случае, если значение отличается от HW MTU. Но, в отличие от IP MTU, любое изменение HW MTU меняет значение MPLS MTU до значения HW MTU (IP MTU это действие не меняет).

MTU на коммутаторах Cisco.

На заметку администратору.

1) Для того, что бы найти минимальный MTU (забавное сочетание) на сети можно использовать расширенную команду ping, причём как c конечных станций/серверов так и с оборудования Cisco. Пропингуем с маршрутизатора R01 маршрутизатор R02 с выставленным df-bit, c начальным размером пакета в 1000 байт, конечным 1500 байт, и шагом 100 байт. Кол-во повторений 2.

Как видите, проходит только 6 ICMP пакетов размером 1000, 1100, 1200, 1300 байт
Начиная с 1400 байт и выше пакеты не проходят. Следовательно, минимальное MTU между двумя точками — 1300 и 1400, что можно уточнить ещё за несколько циклов, ужимая диапазон и умешьшая шаг.

На этом всё. Есть ещё в закромах старый драфт статьи по размерам фреймов и их эволюции, где описаны понятия Jumbo Frame, Baby-Giant Frame, встречающиеся в этой статье. Если посчитаете нужным, могу доработать и выложить и её.

Источник

Пакетный обмен данными по UART

Введение

На сегодняшний день существует много способов организовать обмен данными между Desktop-приложением и устройствами на микроконтроллерах: Wi-Fi, Bluetooth, RF, USB, преобразователи интерфейсов и т.д.

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

В случае использования интерфейсов RS-232, RS-485, RS-422 или чистого UART организация пакетного обмена данными ложится на программиста.

В данной статье я хотел бы рассказать о своей реализации обмена данными между устройствами

Постановка задачи

Нужно отправить из Qt-приложения пакет данных на устройство с микроконтроллером STM8. К компьютеру присоединён USB-RS485 преобразователь, а на устройстве соответственно преобразователь RS485-UART. Нужно учесть, что на линии связи возможен высокий уровень помех. В этой ситуации было принято решение написать быструю и легкую библиотеку для гарантии целостности принятых данных. *Гарантию доставки данных брала на себе бизнес-логика. Библиотеку решил назвать Sheller.

Требования к разрабатываемой библиотеки были следующие:

Фиксированная длинна пакета: количество байт, которые пользователь хочет передать не влияют на общую длину пакета, она остается фиксированной;

Минимальное количество внутренних буферов;

Наличие надежной, быстровычисляемой контрольной суммы;

Побайтного занесения данных;

Возможность работы в условиях поврежденных и потерянных байт в пакете;

Выполнение задачи

Принцип работы: определимся с понятием пакета. Пакет представляет собой стартовый байт, данные пользователя и два байта контрольной суммы CRC-16:

В начале использовался алгоритм контрольной суммы CRC8, однако в ходе тестов было выяснено, что при длине пакета в 8 байт количество коллизий было слишком высоким. Тест заключался в следующем: некоторые пакеты специально отправлялись битыми (менялись значения или вовсе удалялся байт из пакета). В итоге на каждый 50000й пакет происходила коллизия CRC и неправильный пакет передавался в бизнес-логику.

Первый случай коллизии происходил, когда значения байтов в пакете были изменены таким образом, что их контрольная сумма осталась прежней:

А во втором случае часть побитого пакета с частью целого пакета соединялись в один пакет, который проходил по контрольной сумме:

*Красной чертой обозначен пакет, последние байты которого не дошли до приемника. Зеленой чертой показан нормальный пакет. Синей чертой изображен пакет, который был отправлен в бизнес-логику.

Поэтому было принято решение перейти на CRC16. При запуске тоже теста было пройдено более 2млн пакетов без коллизий и тест был завершен удачно. Вычисление контрольной суммы происходит по табличному методу для ускорения работы.

В качестве StartByte используется значение 0x23. С помощью этого числа парсер делает предположение, что с этого места начинается пакет. Далее парсер проверяет количество байт в буфере и если их столько же или больше чем длинна пакета, то производится подсчет контрольной суммы. Если подсчитанная и принятая контрольные суммы совпадают, то пакет выдается и бизнес логику приложения.

При приеме байтов мы записываем их в циклический буфер, в основном я это делаю в обработчике прерывания принятого байта.

Работу всей библиотеки можно описать следующей схемой:

Данная библиотека реализована на Си и на C++. C++ версия предназначена в основном для Arduino.

Для проверки работы Sheller на микроконтроллере был написан ShellerTerminal:

*представляет собой обычный COM-port терминал с использованием алгоритма Sheller.

Информацию по использованию библиотеку вы можете найти на GitHub.

Источник

Ping большими пакетами команда

Команда PING это, пожалуй, самая используемая сетевая утилита командной строки. PING присутствует во всех версиях всех операционных систем с поддержкой сети и является простым и удобным средством опроса узла по имени или его IP-адресу.

Формат командной строки:

ping [-t] [-a] [-n число] [-l размер] [-f] [-i TTL] [-v TOS] [-r число] [-s число] [[-j списокУзлов] | [-k списокУзлов]] [-w таймаут] конечноеИмя

-t — Непрерывная отправка пакетов. Для завершения и вывода статистики используются комбинации клавиш Ctrl + Break (вывод статистики и продолжение), и Ctrl + C (вывод статистики и завершение).
-a — Определение адресов по именам узлов.
-n число — Число отправляемых эхо-запросов.
-l размер — Размер поля данных в байтах отправляемого запроса.
-f — Установка флага, запрещающего фрагментацию пакета.
-i TTL — Задание срока жизни пакета (поле «Time To Live»).
-v TOS — Задание типа службы (поле «Type Of Service»).
-r число — Запись маршрута для указанного числа переходов.
-s число — Штамп времени для указанного числа переходов.
-j списокУзлов — Свободный выбор маршрута по списку узлов.
-k списокУзлов — Жесткий выбор маршрута по списку узлов.
-w таймаут — Максимальное время ожидания каждого ответа в миллисекундах.

ping google.com — эхо-запрос к узлу с именем google.com с параметрами по умолчанию — количество пакетов равно 4, длина массива данных = 32 байта.

ping w 5000 ya.ru — пинг с таймаутом ожидания равным 5 секунд ( по умолчанию — 4 сек).

Применение PING для пошаговой диагностики проблем доступа в Интернет:

Обобщенная схема соединения компьютера (планшета, ноутбука домашней сети) с удаленным конечным узлом можно представить следующим образом:

Команда PING можно использовать для диагностики отдельных узлов:

ping 127.0.0.1 — это пинг петлевого интерфейса. Должен выполняться без ошибок, если установлены и находятся в работоспособном состоянии сетевые программные компоненты.

ping свой IP или имя — пинг на собственный адрес или имя. Должен завершаться без ошибок, если установлены все программные средства протокола IP и исправен сетевой адаптер.

ping IP-адрес роутера — должен выполняться, если исправна сетевая карта компьютера, исправен кабель или беспроводное соединение, используемые для подключения к роутеру и исправен сам роутер. Кроме того, настройки IP должны быть такими, чтобы адрес компьютера и роутера принадлежали одной подсети. Обычно это так, когда сетевые настройки выполняются автоматически средствами DHCP-сервера маршрутизатора.

В результате выполнения данной команды отображается и трассировка маршрута:

Статистика Ping для 87.250.251.11:

Пакетов: отправлено = 1, получено = 1, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 36мсек, Максимальное = 36 мсек, Среднее = 36 мсек

В данном примере, между отправителе и получателем пакетов выстраивается цепочка из 9 маршрутизаторов. Нужно учитывать тот факт, что в версии утилиты ping.exe для Windows, число переходов может принимать значение от 1 до 9. В случаях, когда этого значения недостаточно, используется команда tracert

Отсутствие эхо-ответа не всегда является признаком неисправности, поскольку иногда по соображениям безопасности, некоторые узлы настраиваются на игнорирование эхо-запросов, посылаемых PING. Примером может служить узел microsoft.com и некоторые маршрутизаторы в сетях небольших провайдеров.

Использование PING в командных файлах.

ping 456.0.0.1 — ping на несуществующий адрес

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

При проверке связи не удалось обнаружить узел 456.0.0.1. Проверьте имя узла и повторите попытку.

ping yandex.ru — ping на адрес узла yandex.ru

Ответ на ping доступного узла:

Обмен пакетами с yandex.ru [87.250.250.11] по 32 байт:
Ответ от 87.250.250.11: число байт=32 время=10мс TTL=55

В более простом варианте можно использовать команды:

PING yandex.ru |find «TTL=» && ECHO Yandex pingable — команда ECHO выполняется, если значение ERRORLEVEL, установленное FIND равно 0, т.е узел yandex.ru отвечает на ping.

PING Server64 |find «TTL=» || ECHO Server64 not pingable — команда ECHO выполняется, если значение ERRORLEVEL, установленное FIND не равно 0, т.е. узел Server64 не ответил на ping.

Параметры команды ping и их описание

Windows

Для просмотра в Windows также используйте команду ping /?

Примеры использования

Простой пример использования команды ping

Примерный ответ с исправной связью:

Обмен пакетами с yahoo.com [206.190.36.45] с 32 байтами данных:
Ответ от 206.190.36.45: число байт=32 время=191мс TTL=47
Ответ от 206.190.36.45: число байт=32 время=191мс TTL=47

Пример ответа, если узел недоступен:

Обмен пакетами с yahoo.com [206.190.36.45] по с 32 байтами данных:
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.

* до удаленного узла нет сигнала. Возможно, существуют неполадки на сети.

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

* не удалось определить имя узла. Возможные неполадки: нет связи с DNS, не работает DNS, запрашиваемого имени узла не существует.

Открытие порта для Ping

Справедливо заметить, что не во всех случаях отсутствие ответа на ping означает, что удаленный узел недоступен. Администратор ресурса может намеренно отключить ответы на эхо-запросы.

Также важно знать, что ping не использует конкретный номер порта. Чтобы открыть возможность пинга, необходимо либо найти соответствующую опцию (во многих домашних роутерах) или разрешить ICMP (Internet Control Message Protocol) на брандмауэре. Ну, или наоборот — чтобы закрыть возможность пинга, блокируем запросы ICMP.

Проверка портов

С помощью команды ping нельзя проверить открытость того или иного порта.

Для этих целей используется команда telnet или программа, например, nmap.

Администрируем и настраиваем Windows, Linux.

Думаю любой администратор знает команду ping, которая используется для проверки доступности хостов. Если вы опытный администратор, вероятнее всего вы не узнаете ничего нового из этой статьи. Если же ваши знания ограничиваются банальным ping ya.ru, советую дочитать статью до конца.

Пример 1. Изменение интервала времени между отправкой пакетов

Увеличение интервала

Пример: Ждем 5 секунд перед отправкой следующего пакета.

Уменьшаем интервал

Пример: Ждем 0.1 секунду перед отправкой следующего пакета.

Заметка: Только суперпользователь может указывать интервал меньше 0.2 секунды. В противном случае вы увидите такое сообщение.

Пример 2. Проверка локального интерфейса

Перед проверкой удаленного хоста сначала рекомендуется проверить все ли в порядке с вашим локальным интерфейсом. Для этого можно использовать следующие 3 метода.

Пингуем ноль (0)

Это самый простой и быстрый способ:

Пингуем по имени

Пингуем по IP

Не должно быть никаких потерь пакетов.

Пример 3. Послать N пакетов и завершить работу

В следующем примере мы отправим 5 пакетов.

Пример 4. Версия команды ping

Пример 5. Флуд в сети

Пример 6. Звуковой сигнал

Эта опция исползуется редко, но бывает очень полезна. Вы запускается пинг, ответа от хоста нет, вы разбираетесь в чем дело, и как только проблема будет решена и удаленный хост ответит, вы услышите звук.

Пример 7. Печатать только статистику выполнения команды

Пример 8. Изменение размера пакета

Пример: Изменим размер пакета с 56 до 100.

Пример 9. Длительность выполнения команды

В следующем примере мы будем пинговать локалхост в течение 5-ти секунд.

Пример 10. Краткая статистика с SIGQUIT

Не прерывая команду пинг, можно посмотреть статистику выполнения. Для этого нужна нажать CTRL + |

Полезные ссылки

Лучшая посуда от мировых брендов в интернет магазине: BergHOFF, Luminarc, Vitesse

Источник