Всем доброго времени суток. Уже совсем измучился... Нужно отправить чисто ethernet фрейм + vlan tag + свои данные. Т.е. только канальный уровень по ОСИ.
Взял LwIp библиотеку. Как я понял в ней отправка данных происходит через буфер pbuf и при помощи функции low_level_output().
Собственно сделал свои структуры дабы время сэкономить:


Дальше заполняю и отправляю вот так:



Длина одного фрейма порядка 820 байт... Фреймы передаются,но wireshark периодически показывает "Malformed packet". И в error появляется "#define ERR_BUF -2 /* Buffer error. */" Что я делаю не так ? Как правильно использовать буфер ? помогите плиз, знающие люди !!!
И второй вопрос, фрейм передается правильно, но vlan tag вырезается почему-то, оно где-то разрешаться должно чтоли ?

п.с. с фреймами меньшей длины такие проблемы возникают, но реже

может ли это быть связано с повреждением микросхемы физического уровня ?

Сообщение отредактировал Fobes - Mar 13 2016, 16:27

Я не особо "Знающий" но выскажусь. Такая ошибка в low_level_output и ниже происходит только в одном месте:

В связи с этим вопрос: как часто посылаете? Какие размеры ETH_TX_BUF_SIZE и ETH_TXBUFNB?



Тут я не знаю, но, возможно, если вы не используете lwip, то есть смысл и не использовать pbuf_alloc, а делать пакет pbuf полностью самостоятельно.

Сообщение отредактировал cyrax0 - Mar 14 2016, 07:44

Посылаются пакеты двух типов, 127 байт - 4000 раз в секунду, 817 байт - 1600 раз в секунду.






А вот тут поподробнее можно или что почитать ?

Не кратные циклы получаются, вы не из разных прерываний посылаете пакеты? В некоторых реализациях low_level_output нет проверки на занятость функции, это может привести к проблемам...

Попробуйте сделать такие константы:
#define ETH_TXBUFNB 20 (лучше максимум, на сколько хватит места)
#define ETH_TX_BUF_SIZE 820

Если и на 20 не хватит места, то сделайте ETH_TX_BUF_SIZE 128 (этот вариант не могу рекомендовать, т.к. в параллельной теме у меня проблема как раз с посылкой пакетов, не влезающих в один сетевой буфер).


Ну почитайте про pbuf_alloc, раз в нем не уверены, или создайте полностью struct pbuf, описанную в pbuf.h, без вызова этой функции. По идее, если посылка у вас идет, вызов сделан корректно, но лучше разобраться в функции, а такие ее параметры я не изучал, так что не подскажу, верны они или нет.

Телепаты в отпуске, попробую угадать. Под виндовс влан теги стрипаются драйвером до снифера

Попробовал. ERR_BUF пропала, появилась #define ERR_USE -8 /* Address in use. */ и тот же Malformed packet в шарке...
Сейчас отправляю вообще только 1 тип пакетов, на 817, даже не из прерываний а просто в главном цикле, пытаюсь понять причину не верной работы... Ради интереса выставил задержку между пакетами в 0.1с low_level_output перестал выдавать какие-либо ошибки, но шарк по прежнему периодически показывает Malformed packet... Может ли это быть неисправность физики ethernet или самого stm32f4 ?



Т.е. от других устройств ничего не стирается, а от моего ему не нравятся и он их обрезает ?) Причина в чем-то другом.

Эмм, такая ошибка возникает тоже в одном месте. Если ETH_TX_BUF_SIZE 820, то получается, что 817 вы назвали размер данных, а не целого пакета по логу wireshark. Если же нет, то вам надо поставить брекпоинт на это место и посмотреть, почему он происходит (по факту, похоже, что у вас пакеты делятся, а не должны). Или верните размер 1520, ошибка должна исчезнуть. Но это не относится к главному вопросу; по сути, эта и предыдущая ошибки указывают, что MAC не успевает отослать прежде чем вы пытаетесь передать следующие пакеты, что странно, потому что в моем случае данный контроллер выдает порядка 30000 пакетов (правда меньшего размера) в while(1) при числе буферов 20. Попробуйте udp-посылки с той же частотой или udp-client из куба, посмотрите как он заработает.


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


Мое мнение, что это очень маловероятно.

Именно по этому и пишу про возможное повреждение... я сжег лапу МК большим током, и ethernet phy и stm32f4 питались от одной шины. Теоретически мог что-то повредить, именно после этого началась эта веселуха с пакетами, до этого все вроде верно работало.



В while(1) отправляю сейчас один и тот же пакет, без изменений. Ошибки постоянно разные.... Начиная от верных пакетов и заканчивая пакетами совершенно другой длины с другими типами и не верными контрольными суммами...

Ну, такого я не предполагал. Имхо остается проверить стандартный пример и другой контроллер. Может, кто подскажет еще что.

Новое железо заказал, жду... Не подкините примерчик для проверки, дабы время сэкономить ?

Ну что же вы, батенька, про куб не знаете ?

http://www.st.com/st-web-ui/static/active/...stm32cubef4.zip

Знаю)) Но использую его только как своебразный даташит )) Не понравился мне hal)) Посмотрел архив, конкретных примеров не нашел) Может просто покажете кусок кода, отправляющий любой пакет(чем больше тем лучше) и работающий верно в бесконечном цикле, чтобы было с чем сравнить всетаки, без шанса самому наврать.

Плохо ищете...
STM32Cube_FW_F4_V1.11.0\Projects\STM324xG_EVAL\Applications\LwIP\LwIP_UDP_Echo_Client (вместо STM324xG_EVAL см. ваш контроллер)
udp_echoclient_send, который у них сделан в коллбэке, перенесите в while(1), и получите, видимо, то, что хотите.

Приношу свои извинения) Забыл что с других устройств снимал данные под линуксом) Вопрос с влан тегом снят. Все верно отправляется.




Посмотрел всетаки свой код, при отправке моих пакетов никаких ошибок не вылетает, но шарк ругается по прежнему, буду надеяться что это неисправность железа всетаки)