Контрольная сумма UDP, Помогите понять Опции

[s.i.suprun]

Товарищи форумчане, возникла срочная необходимость написать свою реализацию IP стека, но по ходу возникла проблема подсчета контрольной суммы UDP датаграммы. Если можна поскажите толковое руководство по алгоритму или же если не тяжело пошаговое обьяснение (за илистрацию примером из пары тройки двухбайтных слов отдельное СПАСИБО!!!!!)

Сообщение отредактировал s.i.suprun - Jul 12 2010, 09:42

[adnega]

Код

#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/

[Костян]

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

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

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

[adnega]

Если в поле CRC будет 0, то windows-socket, вроде, примет пакет. Если CRC будет неверна, то пакет отбросится?

[iosifk]

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

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

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

Ну это все шутки...
А так по жизни, неправильные пакеты через сеть не пойдут, если только эта сеть не "точка-точка"...
Потому что сеть умеет только "по уставу"... Только по 802.3 и по другому никак... Положено - сделайте...
Когда я отлаживал МАС в Альтере, то программа мониторинга пакетов долго не могла понять, что я не формировал IP, а просто гнал Ethernet пакеты. Все что не IP или не UDP воспринималось как битые. И я думаю, что точно так же все будет восприниматься и умными свитчами и файерволами... Если я не прав, то те, кто программировал эти штуки пусть меня поправят. Но я ни за что не стал бы делать САМОПАЛ...

[vadimuzzz]

Если в поле CRC будет 0, то windows-socket, вроде, примет пакет. Если CRC будет неверна, то пакет отбросится?

для IPv4 CRC опциональна

[des333]

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

для IPv4 CRC опциональна

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

Может быть, Вы имели в виду, что опциональна контрольная сумма UDP? Тогда Вы правы.

[vadimuzzz]

Может быть, Вы имели в виду, что опциональна контрольная сумма 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

[Костян]

а вот для чего это поле нужно:
"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]

поясните , как то смутно...

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

[Костян]

поясните , как то смутно..

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

я не о переводе, как может датаграма пойти по неверному пути ? Высокоуровневая ошибка приложения ? Так FPGA в общем случае не имеет таких приложений.

[vadimuzzz]

я не о переводе, как может датаграма пойти по неверному пути ? Высокоуровневая ошибка приложения ? Так FPGA в общем случае не имеет таких приложений.

устройство работает только в сетях, где нет ошибок? все маршрутизаторы настроены правильно? пакеты не теряются, не дублируются, приходят в правильном порядке? этого никто не гарантирует.

[x736C]

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

Так это и есть контрольная сумма. (CRC-16).

[des333]

Так это и есть контрольная сумма. (CRC-16).

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


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

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

[s.i.suprun]

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 и т.д. заголовками) и размещается в конце всей посылки.

Сообщение отредактировал s.i.suprun - Jul 13 2010, 07:37

[des333]

2 des333

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


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

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


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

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

[s.i.suprun]

Спасибо большое за ответ.!!!!

[x736C]

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


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

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

Ссылка была на ваш копипаст и ничего, кроме копипаста не показывала.
Признаю, был не прав. CRC-16 совсем другая история.

[des333]

 

Признаю, был не прав. 

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

[adnega]

Эээ... походу это я всех смутил.
Заветные три буквы фигурировали в коде, который выложил в посте #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]

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

Все правильно. Только лучше в таких случаях читать не Таненбаума (хотя не спорю, что книга очень хорошая), а RFC.

[vadimuzzz]

Все правильно. Только лучше в таких случаях читать не Таненбаума (хотя не спорю, что книга очень хорошая), а RFC.

что характерно, судя по посту выше, в SUN`е RFC не читают