передача даных по сети в multicast

[boris_r_v]

Суть проблемы:

Есть некая скада которая опрашивает устройства по rs485 и передает данные в сеть по мульткасту

До сего времени работа только на x86 контроллерах.

После сборки и установки этой же скады, без изменения исходного кода, на контроллер UC-7112-Plus, пакеты udp в которых приходят данные отличаются от пакетам от х86 контроллеров, и не обрабатываются корректно на АРМ.

 

пакет от x86: - good rec

tcpdump host maket_main and port 14350 -nX -s 650

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 650 bytes

10:18:17.627340 IP 192.168.0.56.33079 > 224.1.1.1.14350: UDP, length 74

0x0000: 4500 0066 0000 4000 0211 d6a4 c0a8 0038 E..f..@........8

0x0010: e001 0101 8137 380e 0052 af5e 0000 0000 .....78..R.^....

0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................

0x0030: 0000 0000 0000 0000 2000 0000 0000 0000 ................

0x0040: f401 0000 0100 0143 4455 335f 5069 745f .......CDU3_Pit_

0x0050: 4400 0800 1000 3f00 0700 0000 0000 0000 D.....?.........

0x0060: 0000 0000 0000

 

пакет от arm: - not good rec

tcpdump host moxa-uc and port 14350 -nX -s 650

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 650 bytes

10:21:18.846748 IP 192.168.0.53.1025 > 224.1.1.1.14350: UDP, length 76

0x0000: 4500 0068 0470 4000 0211 d235 c0a8 0035 E..h.p@....5...5

0x0010: e001 0101 0401 380e 0054 2c94 0000 0000 ......8..T,.....

0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................

0x0030: 0000 0000 0000 0000 0000 2000 0000 0000 ................

0x0040: 0000 f401 0000 0100 0143 4455 335f 5069 .........CDU3_Pi

0x0050: 745f 4400 0800 1000 3f00 0700 0000 0000 t_D.....?.......

0x0060: 0000 0000 0000 0000

 

смотрим в строчку 0х0040: f401 0000 0100 0143 - так должно быть а имеем: 0000 f401 0000 0100 0143 - соответвенно данные смещаются, 4455 335f 5069 - это уже полезные данные

 

Вопрос: подскажите в каком месте может быть ошибка?

Либо у меня данные не выровнены как то по особому для АРМ либо разное формирование заголовков пакета.

[boris_r_v]

Решение вопроса нашлось по этому адресу:

http://www.cyberforum.ru/cpp-beginners/thread69549.html

 

Суть - сказать, что не надо выравнивать структуру, правда это, как я понял, не будет работать на ядрах без mmu, но это уже издержки того, что приемник ожидает не выравненную структуру данных, и в моем случае это наложенное ограничение.

Если я не прав насчет того, что не будет работать на адрах без mmu - прошу меня поправить, ибо есть мнение, что на девайсах без mmu - это тоже надо будет запускать.

 

Жду конструктивной критики.

[MuadDib]

Я могу ошибаться, но я не вижу, каким боком mmu относится к делу. Размещение членов структур определяется компилятором, а решения по поводу этого размещения обусловлены в основном требованиями платформы к выравниванию данных. Наличие/отсутствие mmu определяет возможности платформы по гибкому управлению памятью, но никак не выравнивание.

 

Важным моментом, помимо выравнивания и упаковки структур, является размер базовых типов данных. На одной платформе int может быть 4 байта, на другой - 2 байта и т.п. Судя по тому, что лишние 2 байта у вас появились только в одном месте, вполне возможно, что имеет место несоответствие размеров типа данных на разных платформах/компиляторах. В общем, опубликуйте определение структуры, будем посмотреть

 

ИМХО, насиловать ARM-овский компилятор, допуская нарушение выравнивания данных, себе дороже. ARM при работе с невыровненными данными уродует их как бог черепаху (в отличие от x86). Хорошо если в компиляторе этот момент проработан нормально. Тогда вы поимеете только существенное снижение производительности при работе с такими данными. А если нет? Отловить возможные глюки в таком случае будет достаточно сложно. Особенно неприятные моменты могут возникнуть, если в программе используется многопоточность...

[boris_r_v]

Нет все таки косяк был в описании структур, они были не выравненны на dword, а умный gcc - их ровнял. Запретил все гуд, и чтобы не поднимать тему насчет выравнивания отвечаю стразу:

 

Да все ясно, когда в протокол обмена заложено выравнивание на уровне проектирования то все отлично, а когда нет...

Вот нет, это мой случай - __attribute (( packet )) - gcc-ная нашка, помогла, конечно имеем тормоза, но протокол изменить никто не даст, да 60% idle - нормуль.

А вообще на тему выравнивания устроил холивар на http://we.easyelectronics.ru/ARM/rabota-s-ne-vyravnennymi-strukturami-na-armm9.html

 

А насчет mmu - на каком-то форуме прочел, что работа с не выравненными структурами на АРМ это заслуга mmu, удивился - решил спросить у общества. Гранд мерси за ответ.

мир.