alvy 0 15 апреля, 2011 Опубликовано 15 апреля, 2011 · Жалоба Имеется KSZ8841-16MVLI. Задача - передать через нее UDP пакет. С самим пакетом проблем нет - заголовки, контрольные суммы в заголовках - все проверено на приемной стороне Wireshark'ом. Проблема возникла с контрольной суммой CRC32, которая следует после данных, в конце пакета. В даташите на микросхему есть регистр Transmit Control Register (банк 16, адрес 0), в котором, в частности, есть бит "TXCE Transmit CRC Enable". При инициализации записываю в этот бит 1. Но при отправке пакета в Wireshark'е поле контрольной суммы не появляется. Сейчас временно формирую контрольную сумму в ПЛИС, но по идее ее должна формировать сама микросхема - у кого-нибудь получилось заставить ее это делать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 15 апреля, 2011 Опубликовано 15 апреля, 2011 · Жалоба Имеется KSZ8841-16MVLI. Задача - передать через нее UDP пакет. С самим пакетом проблем нет - заголовки, контрольные суммы в заголовках - все проверено на приемной стороне Wireshark'ом. Проблема возникла с контрольной суммой CRC32, которая следует после данных, в конце пакета. В даташите на микросхему есть регистр Transmit Control Register (банк 16, адрес 0), в котором, в частности, есть бит "TXCE Transmit CRC Enable". При инициализации записываю в этот бит 1. Но при отправке пакета в Wireshark'е поле контрольной суммы не появляется. Сейчас временно формирую контрольную сумму в ПЛИС, но по идее ее должна формировать сама микросхема - у кого-нибудь получилось заставить ее это делать? я с Wireshark'ом не работал. Но вот что хочу спросить. Вы смотрите "принятые правильно пакеты" или "поголовно все пакеты, в том числе и неправильные"? Ведь "CRC32, которая следует после данных, в конце пакета" в случае приема правильного пакета может быть отбрасывается? А если она не формируется, то все пакеты должны быть квалифицированы как "неправильные"... Если же Вы делаете "контрольную сумму в ПЛИС", то это возможно трактуется как данные... Проверьте сколько байт данных считывается в этом случае... Так? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alvy 0 15 апреля, 2011 Опубликовано 15 апреля, 2011 (изменено) · Жалоба Вы смотрите "принятые правильно пакеты" или "поголовно все пакеты, в том числе и неправильные"? Если же Вы делаете "контрольную сумму в ПЛИС", то это возможно трактуется как данные... Проверьте сколько байт данных считывается в этом случае... Wireshark показывает все пакеты, даже с неправильными контрольными суммами в заголовках и неправильным или отсутствующим совсем CRC32. Сейчас получается: передаю микросхеме общую длину пакета с заголовками, но без CRC32 - до сетевой карты доходит все, но без CRC. Пробовал указывать длину пакета + 4 пустых (0x00) байта под CRC - в таком же нулевом виде они и показываются в Wireshark'е. Такое ощущение, что микросхема вообще игнорирует указанный в первом посте бит. В случае, когда я сам формирую CRC и добавляю ее в конце пакета, сетевая карта принимает пакет и успешно передает его программе на ПК. Понятно, конечно, что в крайнем случае вариант с ручным подсчетом контрольной суммы вполне подходит, но хотелось бы все таки заставить считать ее в KSZ8841. Обратился в службу техподдержи Micrel, но уже полтора дня ответа не приходит. Изменено 15 апреля, 2011 пользователем alvy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 15 апреля, 2011 Опубликовано 15 апреля, 2011 · Жалоба Wireshark показывает все пакеты, даже с неправильными контрольными суммами в заголовках и неправильным или отсутствующим совсем CRC32. Боюсь, Вы ошибаетесь. Пакеты с неправильной CRC32 не отображаются. Их отбрасывает сам контроллер сетевушки. Собственно говоря, лог Wireshark'а в студию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alvy 0 15 апреля, 2011 Опубликовано 15 апреля, 2011 (изменено) · Жалоба Собственно говоря, лог 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 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 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 Как написано в Wikipedia про Wireshark Программа позволяет пользователю просматривать весь проходящий по сети трафик в режиме реального времени, переводя сетевую карту в неразборчивый режим (англ. promiscuous mode). Изменено 15 апреля, 2011 пользователем alvy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 15 апреля, 2011 Опубликовано 15 апреля, 2011 · Жалоба А прикрепите сюда лог в виде pcap-файла, со всеми потрохами. Немного не хватает тут информации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alvy 0 15 апреля, 2011 Опубликовано 15 апреля, 2011 (изменено) · Жалоба log.7z Там очередность пакетов такая же: сначала пакеты с неправильной контр. суммой, потом с отсутствующей, потом с правильной. Изменено 15 апреля, 2011 пользователем alvy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 15 апреля, 2011 Опубликовано 15 апреля, 2011 · Жалоба log.7z ( 1.81K ) Я просил .pcap-файл, в котором есть все данные, а не текст. Кроме того, рекомендую для отладочных целей выключить offload-checksum на сетевой карте и включить валидацию полей контрольной суммы UDP/TCP в Wireshark'e И кстати, даже по такому логу, обратите внимание на отправляемые компом пакеты в сеть 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) Заметьте, тут нет Frame-Check Sequence. Кстати, что за версия WireShark? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alvy 0 15 апреля, 2011 Опубликовано 15 апреля, 2011 · Жалоба Я просил .pcap-файл, в котором есть все данные, а не текст. Кстати, что за версия WireShark? Извиняюсь, не заметил сразу. С Wireshark'ом работаю всего несколько дней, с ходу не совсем понял, как получить этот самый pcap файл. Как только мне отдадут оборудование постараюсь сделать такой лог. Версия 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 Так что похоже, что действительно все нормально формируется. Как доберусь до оборудования буду проверять. Все, всем спасибо за правильные вопросы и участие - Wireshark действительно не показывает контрольную сумму, НО почему-то есил ее продублировать, то он ее покажет... В общем, CRC микросхемой формируется, пакеты до программы доходят. Тему можно закрывать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 15 апреля, 2011 Опубликовано 15 апреля, 2011 · Жалоба Все, всем спасибо за правильные вопросы и участие - Wireshark действительно не показывает контрольную сумму, НО почему-то есил ее продублировать, то он ее покажет... Потому что Вы ее передаете как данные. И она показывается как данные... Я равботал с Нет-Икс-реем. Так там если контрольная сумма была неправильная, он этот пакет показывал как неправильный, битый и т.д... И только если сумма была правильная, можно было прочесть "начинку" пакета... Я так понимаю, что все эти программы сделаны для разборки протоколов более высокого уровня... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alvy 0 15 апреля, 2011 Опубликовано 15 апреля, 2011 · Жалоба Потому что Вы ее передаете как данные. И она показывается как данные... В том то и дело, что в логах ее видно не как данные - появляется отдельная строчка типа Frame check sequence: 0xc94dafdf [incorrect, should be 0xdee9ac72] Собственно это и сбило с толку. А поскольку опыта работы на этом уровне Ethernet еще не очень много, то и возникли вопросы ) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
