[suprun 0]

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

Изменено 12 июля, 2010 пользователем s.i.suprun

[adnega 11]

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

[Костян 0]

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

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

 

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

 

[adnega 11]

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

[iosifk 3]

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

 

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

Все это напоминает анекдот, когда военный с гражданским едут в поезде, пьют водку и ругаются:

Гражданский: Вы, военные все дураки!

Военный: А вы гражданские, если все такие умные, почему строем не ходите?

 

Ну это все шутки...

А так по жизни, неправильные пакеты через сеть не пойдут, если только эта сеть не "точка-точка"...

Потому что сеть умеет только "по уставу"... Только по 802.3 и по другому никак... Положено - сделайте...

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

[vadimuzzz 0]

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

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

[Des333 0]

То 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 0]

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

 

[Костян 0]

а вот для чего это поле нужно:

"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 0]

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

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

[Костян 0]

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

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

 

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

[vadimuzzz 0]

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

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

[x736C 0]

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

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

[Des333 0]

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

 

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

 

 

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

 

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

[suprun 0]

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

Изменено 13 июля, 2010 пользователем s.i.suprun