Имеется KSZ8841-16MVLI. Задача - передать через нее UDP пакет. С самим пакетом проблем нет - заголовки, контрольные суммы в заголовках - все проверено на приемной стороне Wireshark'ом. Проблема возникла с контрольной суммой CRC32, которая следует после данных, в конце пакета.
В даташите на микросхему есть регистр Transmit Control Register (банк 16, адрес 0), в котором, в частности, есть бит "TXCE Transmit CRC Enable". При инициализации записываю в этот бит 1. Но при отправке пакета в Wireshark'е поле контрольной суммы не появляется.
Сейчас временно формирую контрольную сумму в ПЛИС, но по идее ее должна формировать сама микросхема - у кого-нибудь получилось заставить ее это делать?
Полная версия этой страницы: KSZ8841 и Ethernet CRC
Цитата(alvy @ Apr 15 2011, 08:06) 
Имеется KSZ8841-16MVLI. Задача - передать через нее UDP пакет. С самим пакетом проблем нет - заголовки, контрольные суммы в заголовках - все проверено на приемной стороне Wireshark'ом. Проблема возникла с контрольной суммой CRC32, которая следует после данных, в конце пакета.
В даташите на микросхему есть регистр Transmit Control Register (банк 16, адрес 0), в котором, в частности, есть бит "TXCE Transmit CRC Enable". При инициализации записываю в этот бит 1. Но при отправке пакета в Wireshark'е поле контрольной суммы не появляется.
Сейчас временно формирую контрольную сумму в ПЛИС, но по идее ее должна формировать сама микросхема - у кого-нибудь получилось заставить ее это делать?
В даташите на микросхему есть регистр Transmit Control Register (банк 16, адрес 0), в котором, в частности, есть бит "TXCE Transmit CRC Enable". При инициализации записываю в этот бит 1. Но при отправке пакета в Wireshark'е поле контрольной суммы не появляется.
Сейчас временно формирую контрольную сумму в ПЛИС, но по идее ее должна формировать сама микросхема - у кого-нибудь получилось заставить ее это делать?
я с Wireshark'ом не работал. Но вот что хочу спросить. Вы смотрите "принятые правильно пакеты" или "поголовно все пакеты, в том числе и неправильные"? Ведь "CRC32, которая следует после данных, в конце пакета" в случае приема правильного пакета может быть отбрасывается? А если она не формируется, то все пакеты должны быть квалифицированы как "неправильные"...
Если же Вы делаете "контрольную сумму в ПЛИС", то это возможно трактуется как данные... Проверьте сколько байт данных считывается в этом случае...
Так?
Цитата(iosifk @ Apr 15 2011, 12:38)
Вы смотрите "принятые правильно пакеты" или "поголовно все пакеты, в том числе и неправильные"?
Если же Вы делаете "контрольную сумму в ПЛИС", то это возможно трактуется как данные... Проверьте сколько байт данных считывается в этом случае...
Wireshark показывает все пакеты, даже с неправильными контрольными суммами в заголовках и неправильным или отсутствующим совсем CRC32. Если же Вы делаете "контрольную сумму в ПЛИС", то это возможно трактуется как данные... Проверьте сколько байт данных считывается в этом случае...
Сейчас получается: передаю микросхеме общую длину пакета с заголовками, но без CRC32 - до сетевой карты доходит все, но без CRC. Пробовал указывать длину пакета + 4 пустых (0x00) байта под CRC - в таком же нулевом виде они и показываются в Wireshark'е. Такое ощущение, что микросхема вообще игнорирует указанный в первом посте бит.
В случае, когда я сам формирую CRC и добавляю ее в конце пакета, сетевая карта принимает пакет и успешно передает его программе на ПК. Понятно, конечно, что в крайнем случае вариант с ручным подсчетом контрольной суммы вполне подходит, но хотелось бы все таки заставить считать ее в KSZ8841.
Обратился в службу техподдержи Micrel, но уже полтора дня ответа не приходит.
QUOTE
Wireshark показывает все пакеты, даже с неправильными контрольными суммами в заголовках и неправильным или отсутствующим совсем CRC32.
Боюсь, Вы ошибаетесь. Пакеты с неправильной CRC32 не отображаются. Их отбрасывает сам контроллер сетевушки.
Собственно говоря, лог Wireshark'а в студию.
Цитата(Rst7 @ Apr 15 2011, 13:44)
Собственно говоря, лог Wireshark'а в студию.
1. пакет с неправильной CRC32 (должен быть отброшен сетевой картой). KSZ8841 было указано отправить 112 байт, последними 4 байтами отправлена контрольная сумма (Frame check sequence):
Код
Frame 1: 112 bytes on wire (896 bits), 112 bytes captured (896 bits)
Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Source: OrientPo_01:23:45 (00:13:37:01:23:45)
Type: IP (0x0800)
Frame check sequence: 0xc94dafdf [incorrect, should be 0xdee9ac72]
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100)
User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001)
Data (66 bytes)
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>?
0040 40 41 @A
Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Source: OrientPo_01:23:45 (00:13:37:01:23:45)
Type: IP (0x0800)
Frame check sequence: 0xc94dafdf [incorrect, should be 0xdee9ac72]
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100)
User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001)
Data (66 bytes)
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>?
0040 40 41 @A
2. пакет с отсутствующей контрольной суммой (так же должен быть отброшен сетевой картой). KSZ8841 было указано отправить 108 байт, бит TXCE Transmit CRC Enable взведен, но контрольной суммы нет:
Код
Frame 13: 108 bytes on wire (864 bits), 108 bytes captured (864 bits)
Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Source: OrientPo_01:23:45 (00:13:37:01:23:45)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100)
User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001)
Data (66 bytes)
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>?
0040 40 41 @A
Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Source: OrientPo_01:23:45 (00:13:37:01:23:45)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100)
User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001)
Data (66 bytes)
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>?
0040 40 41 @A
3. пакет с правильной контрольной суммой (принят и сетевой картой и программой). Все так же как и в первом случае:
Код
Frame 14: 112 bytes on wire (896 bits), 112 bytes captured (896 bits)
Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Source: OrientPo_01:23:45 (00:13:37:01:23:45)
Type: IP (0x0800)
Frame check sequence: 0xdee9ac72 [correct]
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100)
User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001)
Data (66 bytes)
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>?
0040 40 41 @A
Ethernet II, Src: OrientPo_01:23:45 (00:13:37:01:23:45), Dst: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Destination: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Source: OrientPo_01:23:45 (00:13:37:01:23:45)
Type: IP (0x0800)
Frame check sequence: 0xdee9ac72 [correct]
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.100 (192.168.0.100)
User Datagram Protocol, Src Port: terabase (4000), Dst Port: newoak (4001)
Data (66 bytes)
0000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ................
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
0030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>?
0040 40 41 @A
Как написано в Wikipedia про Wireshark
Цитата
Программа позволяет пользователю просматривать весь проходящий по сети трафик в режиме реального времени, переводя сетевую карту в неразборчивый режим (англ. promiscuous mode).
А прикрепите сюда лог в виде pcap-файла, со всеми потрохами. Немного не хватает тут информации.
Нажмите для просмотра прикрепленного файла
Там очередность пакетов такая же: сначала пакеты с неправильной контр. суммой, потом с отсутствующей, потом с правильной.
Там очередность пакетов такая же: сначала пакеты с неправильной контр. суммой, потом с отсутствующей, потом с правильной.
QUOTE
log.7z ( 1.81K )
Я просил .pcap-файл, в котором есть все данные, а не текст.
Кроме того, рекомендую для отладочных целей выключить offload-checksum на сетевой карте и включить валидацию полей контрольной суммы UDP/TCP в Wireshark'e
И кстати, даже по такому логу, обратите внимание на отправляемые компом пакеты в сеть
CODE
Frame 3: 248 bytes on wire (1984 bits), 248 bytes captured (1984 bits)
Ethernet II, Src: Wistron_92:0c:a3 (00:1f:16:92:0c:a3), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.255 (192.168.0.255)
Ethernet II, Src: Wistron_92:0c:a3 (00:1f:16:92:0c:a3), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Wistron_92:0c:a3 (00:1f:16:92:0c:a3)
Type: IP (0x0800)
Internet Protocol, Src: 192.168.0.1 (192.168.0.1), Dst: 192.168.0.255 (192.168.0.255)
Заметьте, тут нет Frame-Check Sequence. Кстати, что за версия WireShark?
Цитата(Rst7 @ Apr 15 2011, 15:16)
Я просил .pcap-файл, в котором есть все данные, а не текст.
Кстати, что за версия WireShark?
Извиняюсь, не заметил сразу. С Wireshark'ом работаю всего несколько дней, с ходу не совсем понял, как получить этот самый pcap файл. Как только мне отдадут оборудование постараюсь сделать такой лог. Кстати, что за версия WireShark?
Версия 1.4.4
Только что ответили из Micrel:
Цитата
Wireshark does not capture FCS field of a packet. See FAQ 7.9 and 7.10
for detail information. http://www.wireshark.org/faq.html#q7.9
for detail information. http://www.wireshark.org/faq.html#q7.9
Так что похоже, что действительно все нормально формируется. Как доберусь до оборудования буду проверять.
Все, всем спасибо за правильные вопросы и участие - Wireshark действительно не показывает контрольную сумму, НО почему-то есил ее продублировать, то он ее покажет...
В общем, CRC микросхемой формируется, пакеты до программы доходят.
Тему можно закрывать.
Цитата(alvy @ Apr 15 2011, 13:15)
Все, всем спасибо за правильные вопросы и участие - Wireshark действительно не показывает контрольную сумму, НО почему-то есил ее продублировать, то он ее покажет...
Потому что Вы ее передаете как данные. И она показывается как данные...
Я равботал с Нет-Икс-реем. Так там если контрольная сумма была неправильная, он этот пакет показывал как неправильный, битый и т.д...
И только если сумма была правильная, можно было прочесть "начинку" пакета... Я так понимаю, что все эти программы сделаны для разборки протоколов более высокого уровня...
Цитата(iosifk @ Apr 15 2011, 16:25)
Потому что Вы ее передаете как данные. И она показывается как данные...
В том то и дело, что в логах ее видно не как данные - появляется отдельная строчка типа Frame check sequence: 0xc94dafdf [incorrect, should be 0xdee9ac72]
Собственно это и сбило с толку. А поскольку опыта работы на этом уровне Ethernet еще не очень много, то и возникли вопросы )
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.