Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Контрольная сумма UDP
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
s.i.suprun
Jul 12 2010, 09:40
Товарищи форумчане, возникла срочная необходимость написать свою реализацию IP стека, но по ходу возникла проблема подсчета контрольной суммы UDP датаграммы. Если можна поскажите толковое руководство по алгоритму или же если не тяжело пошаговое обьяснение (за илистрацию примером из пары тройки двухбайтных слов отдельное СПАСИБО!!!!!)
adnega
Jul 12 2010, 09:49
Код
#define    UDP_PACKET_SIZE    8
#define    IP_UDP            17

  // псевдозаголовок
  crc=UDP_PACKET_SIZE+sizeof(sAUDIO_PACKET)+IP_UDP
    +(((DWORD)dst_ip[0]<<8)|dst_ip[1])
    +(((DWORD)dst_ip[2]<<8)|dst_ip[3])
    +(((DWORD)src_ip[0]<<8)|src_ip[1])
    +(((DWORD)src_ip[2]<<8)|src_ip[3]);
    
  // заголовок
  for(j=0;j<((UDP_PACKET_SIZE+sizeof(sAUDIO_PACKET)+1)>>1);j++)
    crc+=(bl0_data[j*2+1+ETH_PACKET_SIZE+IP_PACKET_SIZE]
      +((DWORD)bl0_data[j*2+0+ETH_PACKET_SIZE+IP_PACKET_SIZE]<<8));
    
  crc=(crc+(crc>>16))^0xFFFF;

http://www.opennet.ru/docs/RUS/tcpip
    
  udp->crc=SWAPBYTES(crc);


В поле CRC UDP заносим 0.
Сначала считаем сумму псевдозаголвка (тип пакета 17 + размер данных пакета IP (размер заголовка UDP+размер данных UDP)) + IP адреса источника и получателя.
Потом к полученной сумме добавляем все данные IP пакета (т.е. заголовок UDP и данные UDP).
Затем добавляем переполнение и инвертируем содержимое CRC

bl0_data[ETH_PACKET_SIZE+IP_PACKET_SIZE] - начало пакета UDP

Можно почитать http://www.opennet.ru/docs/RUS/tcpip/
Костян
Jul 12 2010, 11:10
QUOTE (s.i.suprun @ Jul 12 2010, 07:40) *
Товарищи форумчане, возникла срочная необходимость написать свою реализацию IP стека, но по ходу возникла проблема подсчета контрольной суммы UDP датаграммы.

А какой смысл считать crc для UDP ?

разве мало ethernet crc ?
adnega
Jul 12 2010, 11:50
Если в поле CRC будет 0, то windows-socket, вроде, примет пакет. Если CRC будет неверна, то пакет отбросится?
iosifk
Jul 12 2010, 12:15
Цитата(Костян @ Jul 12 2010, 15:10) *
А какой смысл считать crc для UDP ?

разве мало ethernet crc ?

Все это напоминает анекдот, когда военный с гражданским едут в поезде, пьют водку и ругаются:
Гражданский: Вы, военные все дураки!
Военный: А вы гражданские, если все такие умные, почему строем не ходите?

Ну это все шутки...
А так по жизни, неправильные пакеты через сеть не пойдут, если только эта сеть не "точка-точка"...
Потому что сеть умеет только "по уставу"... Только по 802.3 и по другому никак... Положено - сделайте...
Когда я отлаживал МАС в Альтере, то программа мониторинга пакетов долго не могла понять, что я не формировал IP, а просто гнал Ethernet пакеты. Все что не IP или не UDP воспринималось как битые. И я думаю, что точно так же все будет восприниматься и умными свитчами и файерволами... Если я не прав, то те, кто программировал эти штуки пусть меня поправят. Но я ни за что не стал бы делать САМОПАЛ...
vadimuzzz
Jul 12 2010, 12:17
Цитата(adnega @ Jul 12 2010, 18:50) *
Если в поле CRC будет 0, то windows-socket, вроде, примет пакет. Если CRC будет неверна, то пакет отбросится?

для IPv4 CRC опциональна
des333
Jul 12 2010, 12:25
То s.i.suprun:
Пример рассчета:
http://ru.wikipedia.org/wiki/UDP#.D0.9F.D1....BC.D0.BC.D1.8B



Цитата(vadimuzzz @ Jul 12 2010, 16:17) *
для IPv4 CRC опциональна

Контрольная сумма заголовка IPv4 не опциональна. И там используется не CRC, а 16-битовое поразрядное дополнение суммы поразрядных дополнений всех 16-битовых слов заголовка. 

Может быть, Вы имели в виду, что опциональна контрольная сумма UDP? Тогда Вы правы.
vadimuzzz
Jul 12 2010, 12:31
Цитата(des333 @ Jul 12 2010, 19:25) *
Может быть, Вы имели в виду, что опциональна контрольная сумма UDP? Тогда Вы правы.

да, "An all zero transmitted
checksum value means that the transmitter generated no checksum (for
debugging or for higher level protocols that don't care).
"
а вот для чего это поле нужно:
"The pseudo header conceptually prefixed to the UDP header contains the
source address, the destination address, the protocol, and the UDP
length. This information gives protection against misrouted datagrams."

http://www.faqs.org/rfcs/rfc768.html
Костян
Jul 12 2010, 12:57
QUOTE (vadimuzzz @ Jul 12 2010, 10:31) *
а вот для чего это поле нужно:
"The pseudo header conceptually prefixed to the UDP header contains the
source address, the destination address, the protocol, and the UDP
length. This information gives protection against misrouted datagrams."

http://www.faqs.org/rfcs/rfc768.html

поясните , как то смутно...
vadimuzzz
Jul 12 2010, 13:18
Цитата(Костян @ Jul 12 2010, 19:57) *
поясните , как то смутно...

"protection against misrouted datagrams" - заплутала дейтаграмма smile.gif при этом CRC ethernet-пакета верная.
Костян
Jul 12 2010, 14:52
QUOTE (vadimuzzz @ Jul 12 2010, 11:18) *
QUOTE
поясните , как то смутно..

"protection against misrouted datagrams" - заплутала дейтаграмма smile.gif при этом CRC ethernet-пакета верная.


я не о переводе, как может датаграма пойти по неверному пути ? Высокоуровневая ошибка приложения ? Так FPGA в общем случае не имеет таких приложений.
vadimuzzz
Jul 12 2010, 15:30
Цитата(Костян @ Jul 12 2010, 21:52) *
я не о переводе, как может датаграма пойти по неверному пути ? Высокоуровневая ошибка приложения ? Так FPGA в общем случае не имеет таких приложений.

устройство работает только в сетях, где нет ошибок? все маршрутизаторы настроены правильно? пакеты не теряются, не дублируются, приходят в правильном порядке? этого никто не гарантирует.
x736C
Jul 13 2010, 02:25
Цитата(des333 @ Jul 12 2010, 16:25) *
И там используется не CRC, а 16-битовое поразрядное дополнение суммы поразрядных дополнений всех 16-битовых слов заголовка. 

Так это и есть контрольная сумма. (CRC-16).
des333
Jul 13 2010, 06:13
Цитата(x736C @ Jul 13 2010, 06:25) *
Так это и есть контрольная сумма. (CRC-16).


Я писал, что это не контрольная сумма?


Что должна была мне показать Ваша ссылка?

Что контрольная сумма UDP является CRC-16? Не показала.
s.i.suprun
Jul 13 2010, 07:35
2 des333

Пример рассчета:
http://ru.wikipedia.org/wiki/UDP#.D0.9F.D1....BC.D0.BC.D1.8B


Оный пример видел, читал все понятно вод до этой строчки: "0x08c1 = 0000 1000 1100 0001 → 1111 Это и есть искомая контрольная сумма."
Извените за глупые вопросы, но откуда там взялась 0x0F - не могу ума приложить....

Нашел другую доку: http://www.faqs.org/rfcs/rfc1071.html


На счет контрольной суммы в полях заголовков: как в полях транспортных протоколов так и протоколах сетевого уровня данное поле должно быть просчитано и забито (Возможен, правда вариант не просчета этого поля в UDP). Счёт для них происходит по одному алгоритму:поразрядное дополнение до единицы суммы всех 16-битных слов с поразрядным дополнением*(Wiki).
Разница лишь в том, что для UDP, TCP и т.д., сумма считается для всей датаграммы, а в IP - лишь для заголовка. А CRC-алгоритм применяется для подсчета контрольной суммы полностью сформированого пакета (с MAC и т.д. заголовками) и размещается в конце всей посылки.
des333
Jul 13 2010, 07:52
Цитата(s.i.suprun @ Jul 13 2010, 19:35) *
2 des333

Пример рассчета:
http://ru.wikipedia.org/wiki/UDP#.D0.9F.D1....BC.D0.BC.D1.8B


Оный пример видел, читал все понятно вод до этой строчки: "0x08c1 = 0000 1000 1100 0001 → 1111 Это и есть искомая контрольная сумма."
Извените за глупые вопросы, но откуда там взялась 0x0F - не могу ума приложить....


Вполне логичный вопрос.  smile.gif


Там был нормальный пример описан, но статью кто-то неудачно отредактировал. 

Я вернул, как было раньше.

s.i.suprun
Jul 13 2010, 08:10
Спасибо большое за ответ.!!!! a14.gif
x736C
Jul 13 2010, 09:21
Цитата(des333 @ Jul 13 2010, 18:13) *
Я писал, что это не контрольная сумма?


Что должна была мне показать Ваша ссылка?

Что контрольная сумма UDP является CRC-16? Не показала.

Ссылка была на ваш копипаст и ничего, кроме копипаста не показывала.
Признаю, был не прав. CRC-16 совсем другая история.
des333
Jul 13 2010, 09:49
 
Цитата(x736C @ Jul 13 2010, 21:21) *
Признаю, был не прав. 

Ничего страшного. Бывает.  smile.gif


adnega
Jul 13 2010, 10:17
Эээ... походу это я всех смутил.
Заветные три буквы фигурировали в коде, который выложил в посте #2.
Правильнее будет заменить CRC на CS.
Добавлю: опыт показывает, что говорить о CRC-16 без явного указания начального значения, порождающего полинома, и прочих преобразований, иногда не имеет смысла (ибо реализаций CRC-16 много).
В соответствующее поле UDP заносится контрольная сумма.

Посмотрел у Таненбаума ("Компьютерные сети"):
"Контрольная сумма UDP не является обязательной. Если она не подсчитывается, ее значение равно 0 (настоящая нулевая контрольная сумма кодируется всеми единицами).
Отключать функцию подсчета контрольной суммы глупо, за исключением одного случая - когда нужна высокая производительность."

С http://www.opennet.ru/docs/RUS/tcpip/#c5_udp :
"Если поле "Контрольная сумма" UDP-заголовка содержит нулевое значение, это означает, что источник UDP-пакета контрольную сумму не подсчитывал, и приемник выполнять ее проверку не должен. Некоторые реализации протокола UDP (например, в SunOS - клоне ОС UNIX от Sun Microsystems) контрольную сумму не подсчитывают в принципе, полагаясь на возможности контроля целостности данных, реализованные в протоколах сетевого уровня (например, в Ethernet)."
des333
Jul 13 2010, 10:39
Цитата(adnega @ Jul 13 2010, 22:17) *
Посмотрел у Таненбаума ("Компьютерные сети"):
"Контрольная сумма UDP не является обязательной. Если она не подсчитывается, ее значение равно 0 (настоящая нулевая контрольная сумма кодируется всеми единицами)."


Все правильно. Только лучше в таких случаях читать не Таненбаума (хотя не спорю, что книга очень хорошая), а RFC.
vadimuzzz
Jul 13 2010, 14:57
Цитата(des333 @ Jul 14 2010, 01:39) *
Все правильно. Только лучше в таких случаях читать не Таненбаума (хотя не спорю, что книга очень хорошая), а RFC.

что характерно, судя по посту выше, в SUN`е RFC не читают smile.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.